You are here

Smashing Magazine

Subscribe to Smashing Magazine feed
Recent content in Articles on Smashing Magazine — For Web Designers And Developers
Updated: 26 min 18 sec ago

Smashing Podcast Episode 3 With Jina Anne: What Are Design Tokens?

2 hours 40 min ago
Smashing Podcast Episode 3 With Jina Anne: What Are Design Tokens? Smashing Podcast Episode 3 With Jina Anne: What Are Design Tokens? Drew McLellan 2019-11-19T05:00:00+00:00 2019-11-19T07:08:25+00:00

In this episode of the Smashing Podcast, we’re talking about Design Tokens. What are they, what problem do they solve, and how can they be used within an existing Design System? Drew McLellan talks to someone who is much more than a token expert: Jina Anne.

Show Notes Transcript

Drew: She’s a design systems advocate and coach. While at Amazon, she was senior design systems lead and she was lead designer on the Lightning Design System at Salesforce, while at Apple she led the CSS architecture and style guide for the Apple Online Store. She’s worked with GitHub, Engine Yard, and the Memphis Brooks Museum of Art and more. She founded and organizes Clarity, the first design systems conference, and is on the Sass core team where she leads the brand design and website for Sass. When it comes to design systems, you’d be hard pushed to find anyone more qualified, but did you know that she’s never seen a sidewalk? My smashing friends, please welcome Jina Anne. Hello, Jina.

Jina Anne: Hello.

Drew: How are you?

Jina Anne: I’m smashing.

Drew: I wanted to talk to you today about design tokens, which I think is a phrase many of us have probably heard passed about, but we perhaps aren’t sure what it means. But before we get to that, I guess we should talk a little bit about design systems. I mean, design systems are your thing, right?

Jina Anne: Yeah. It rules everything around me. Yeah.

Drew: I think that there’s something that we’re seeing is becoming increasingly common in projects and people are making them public and seems to be a real movement around design systems. But I think there are plenty of organizations that don’t have them in place still. What problem does a formalized design system solve from your point of view?

Jina Anne: It can solve many problems. I think some of the more common problems that people seek to solve is around maintainability and consistency. That usually has to do with design debt or in some cases code debt, some cases both. I also look at it as a… Like, it’s not just about the code or the design, but also the problems around how people work together. So, I look at it as a way to also solve some of the issues around communication and workflow process and so on.

Drew: Are design systems then something exclusively that are useful to really big teams and big organizations?

Jina Anne: I don’t think so. I’ve seen them work really well with smaller teams or sometimes even with a lone designer. They definitely help with larger teams for sure, but they are definitely not exclusive to large teams. In fact, I think if you see yourself perhaps growing at some point to be a large team, then having the system in place already will help you do that more efficiently.

Drew: What did you think are the sort of symptoms that somebody might be looking for if they’re working and they’re still having problems? What do those problems look like that might be solved by putting a design system in place?

Jina Anne: There’s a few, duplication of efforts, duplication of code. You might have a breakdown in communication where things just aren’t being built the way they’re expected to be built. It could come down to things that aren’t documented well, so people don’t really quite know what the best thing is to use or where to look. Yeah, there are all sorts of signs.

Drew: I guess design systems are generally a concept, rather than a specific technical solution. In your work, you must see people using all sorts of different tools to achieve design systems.

Jina Anne: Yeah.

Drew: What are some of the more common ways that people actually go about it?

Jina Anne: I think the most common ways are having a component library done in code and often cases you’ll see it in it like a React library or an Angular library, whatever, platform you’re using. There’s usually also a website associated with it that will display those components. Then you’ll usually see perhaps like a Sketch or a Figma library as well.

Jina Anne: But one of the things that I like to stress to people is that if you look at that website that displays your documentation and your components, that website is not actually your design system. It’s a representation of your design system. So, I think a lot of people spend a lot of time on making this gorgeous, beautiful website and it’s fine. They’re nice to look at and they’re nice to share and they help a lot with communicating what you’re doing and even with recruiting.

Jina Anne: But it’s the system itself that it represents that I want people to spend their love and care into, so thinking through what’s going into that website, like the content and how you’ve organized things, how you’ve named things, the things that you’re systemizing, so, yeah. I think a lot of people think about the artifacts, like the deliverables, but really it’s a lot more than that. It’s a lot of process and workflow as well.

Drew: Is it exclusively web projects that the design system would help with?

Jina Anne: Not at all. It is the most common, I believe, from, at least, what I’ve seen, but design systems definitely can cover many things. In the digital space, you have native platforms, but even outside the digital space, I think a lot of people talk about design systems in a digital product space. But they’ve been around for ages for traditional medias and real-world scenarios. If you have seen the NASA graphic standards manual from like the ‘70s, that was a design system. It just was across all the different like rockets and spacesuits and all that, instead of digital products.

Drew: So, I guess, there must be some overlap between things, traditional things like brand guidelines and that sort of documentation that I think probably people are familiar with in all sorts of walks of life. There must be a crossover between that sort of documentation of a system and a more modern concept of a design system.

Jina Anne: Yeah, I believe so. I think a lot of people forget that it’s all about branding. The whole reason any of this even started and why we want to display these things in a uniform or unified way is all about the brand because brand isn’t just logos. It’s how people use and experience your company’s service or product or whatever it is that you offer. So, yeah, absolutely.

Drew: So, I’ve got a design system in place, I mean an organization. We’ve done a whole lot of work. We’ve got a design system. There are creatives within the organization working in maybe, like you mentioned, Figma or Sketch. We’ve got web designers using that in a CSS. Perhaps we’ve got a mobile team doing like Android and iOS development, building apps. Loads of people working with a design system contributing into it and consuming stuff from it. Where do design tokens come in? What problem do they solve?

Jina Anne: Ooh, yes. Let me first take it back to a story. When I first joined at Salesforce, I was actually part of a small project team. It was a different product, it’s like a productivity tool like tasks and notes and things like that. We were only three designers and I was the only one that, I guess, I wouldn’t say brave enough, but maybe interested enough to work with the Android designs. The other two designers, I think, just weren’t quite as interested. So, I was basically the main designer on our Android app. Then I also did a lot of design for iOS app and, of course, the web application as well and the marketing website, so lots of different projects in play.

Jina Anne: With the website, since I like to design and code, it was pretty straightforward. I could go ahead and build the buttons and typography and everything that we needed for the web application or the marketing website, document it in code and deliver that.

Jina Anne: However, with both the Android and iOS app, I don’t really know how to code for that and so I wasn’t able to deliver the same thing. So, I was having to do a ton of redlines specs, which, if you’re not familiar with redlines, it’s essentially where you are specking out every single spacing, font size, color, anything to indicate how to build it for the engineer. I would do these for many, many, many screens and, of course, a lot of those screens had variations because maybe you’re showing what happens when you clicked that button or when a certain state happens. So, doing this across many, many screens and then saving those up to Dropbox and then documenting it in a Wiki. That was the process that I was having to do at the time.

Jina Anne: I usually think about things in a CSS way, like especially the C in CSS, so I usually think, “Oh, well, font sizes should only need to be declared one time because it’s going to cascade everywhere.” But I found that with certain engineers that I’ve worked within the past, if you don’t spec it, and I guess with native it works a little differently, they’re not going to build it and so I would have to be very explicit and name pretty much everything per screen. I was just like, “Oh, why is it like this?” Then any time we made any changes, I had to go back through and change all those screens again. It was not fun at all.

Jina Anne: Fast forward to when I moved over to the core team of Salesforce, I had been working in the Sass website and I’ve been playing around with using a YAML file to store the data for colors, typography, spacing and so on and was looping over that data to create the style guide, as well as the Sass variables in the classes. The reason I did that was we open-sourced the Sass website and I wanted people to be able to contribute to the design as well. But I didn’t want to make it a tedious process where you had to update the style guide along with any colors that you’re adding and so doing it this way, just kind of automated that process.

Jina Anne: I showed that to the team at Salesforce and then that kind of is where the concept of design tokens spawned off of. So they built a tool called Theo and there’s other tools out now that do the same thing like Style Dictionary. But the idea of it is you have this automated tool that takes the data that you give it and generates the code. You might think, “Well, that might be over-engineering variables. Why not just use variables?”

Jina Anne: Well, the idea is, as you alluded to earlier, like native platforms just take those attributes in a totally different way and so trying to scale design to Android and iOS, whatever other platforms that get Salesforce. We had some people on Java, we had some people on React yet, some people on Angular, PHP, not just internally at Salesforce, but also externally with all our partners and customers that were building their own applications. So, this was a way to store our visual information as data and then, in an automated way, generate the variables or the XML data you needed or the JSON data, whatever format that particular platform looked for.

Jina Anne: Then what was great about it was we found, let’s say a color doesn’t pass contrast ratios. I didn’t have to then notify the Android team and the iOS team and the web team. I just made that change and then they would get that change automatically the next time that they would pull in the latest. So, it just really helped streamline a lot of that and helped us be able to take off some of the burdens of updating visual designs from the engineers and that let us do that.

Drew: So, instead of being sort of variables within one particular code base, within your own React codebase or within your PHP or within your Java or wherever, they’re like variables across an entire organization? Is that fair to say?

Jina Anne: Correct. Correct. Then what’s cool is things like colors, for example, like transparent colors, you do that differently in Android, like eight-digit hex, instead of RGBA like you would with web. So that tool that you use, if you’re using one that is built to think through all this, does that transformation for you. So, rather than saying RGBA 50 comma, 40 comma, whatever the color, you can just say color background card or something like that. It’s really more of a named entity now and then you can all be speaking the same language, even though it might render a different syntax.

Drew: Right. So, although variables kind of the nuts and bolts of how it might be implemented, the idea is kind of much bigger than just what you’d think of as just variables. I mean, I guess in a way like RSS could be called just variables. But, actually, the way it enables us to distribute blog content and podcasts and everything has a much wider impact than just the core technology that’s there.

Jina Anne: Yeah, I think that’s actually a really good metaphor. I do see a lot of people when they use it or talk about it in their own design system website, they’re usually only talking about like Sass variables or CSS variables. I think that’s why there’s this confusion, like, “Well, isn’t that just variables?” It’s, like, “Why are we renaming it?” But it is that much broader application of it with a whole process around it. It even gets into like how you distribute those variables across components, like on a global level or on an individual component level. You can have multi-layers and so on. It can get pretty interesting.

Drew: So, I suppose as well as helping in the maintenance, you mentioned being able to change a color in one central location and then have everything that is, using those design tokens, be able to pick it up when the next build or next refresh from the system, presumably this has the potential to enable all sorts of other interesting things. I know a lot of people make sort of white-labeled products. It’s the same core product, but it’s customized with different design tweaks for different and things. So, using design tokens could actually be a solution for those sorts of applications as well, the need to span more than just one particular codebase.

Jina Anne: Right. Yeah. So, that was definitely a use case at Salesforce. We have a lot of, I don’t know why I’m still using present tense, but we had a lot of customers that wanted to be able to brand their UI that they were using. So, we had this concept of certain variables that we wanted to actually be seen more as like a constant, like maybe it’s an error color versus colors that were meant to be configured, like brandable colors. So, for some people’s needs that can get interesting, too, white labeling or offering any sort of theming, dark mode or night mode, even offering a feature, which you may have seen in Gmail, but it’s like that comfortable, cozy, compact spacing density. So, there are all sorts of extra stuff that you can get with it across multiple products very quickly, which is really nice.

Drew: It is really an extension of core principles of programming where you make sure that you’ve really defined things once in one place, so you don’t have multiple instances so it’s easy to update. But it is looking at that as a much, much bigger idea than just one small element of a product, looking at it across everything and centralizing that.

Jina Anne: Yeah, so we definitely looked at these as our source of truth. However, in case anybody is worried about like, “Well, Android does things differently than iOS,” or you might have some concerns there. Depending on how you’ve architected things, you can still solve for those use cases. So, we would have a global token set that all our products would basically import in, but then we made them in a way where you could either alter it for that particular context or extend it, like offer maybe additional tokens that only that particular context needs. So, you can still give the fine-tune experience that you need to give to each of those context, while bringing in the most common shared things.

Drew: On a technical level, how would this actually work? Is there like a common file format the different systems share? Is there like an established standard for how you declare your design tokens?

Jina Anne: It’s interesting that you asked that. There’s actually a community group formed through… W3C has all these community groups. It’s not really exactly a working group, but it’s still like an initiative across various people that are in this space trying to come up with a recommendation of what those standards could be. Even how people store their data can change. Like it could be YAML, it could be JSON, it could even be a spreadsheet. Then what you export would be different because you might be using Sass, you might be using LESS, you might be using some sort of XML base system. We actually don’t want to tell you which of those things to use because depending on our use case, you might need to use spreadsheets instead of JSON or YAML or you might need to use XML instead of Sass or LESS or even CSS variables. That’s because everybody’s products are so different and have different needs.

Jina Anne: But what we can standardize on is around the tooling to generate these things. The reason we want to try to come to some sort of standard is because so many design tools are starting to implement this, InVision, Adobe, Figma. All these tools are looking at design tokens because there is a need to not just make this a code-based thing, but make this a design tool-driven thing as well. We don’t want to do it in a way where those tools don’t feel like they can innovate. We want them to be able to innovate, but at least offer some sort of standards so that new tool-makers can get into this space and already have sort of an established understanding of how to set that up. So, while we’re not going to get strict on your format of what file format you’re using or what tool you’re using, we’re going to more try to standardize on like the internal process and basically the API of it.

Drew: Because like I said, once that API has been defined, the tooling can spring up around it that speaks with that API for whatever tools that people want to use. So, somebody could write up a Java library that speaks that API, and then anything that’s using Java could make use of it and so on. Are there any tools currently that support design tokens in any way?

Jina Anne: Yeah. On the code side, I mentioned already Theo and Style Dictionary. There’s also one called Diez, D-I-E-Z. That’s kind of newer to the space and it’s taking it beyond, just like doing the transformation process, but kind of treating design tokens as a component in a way and so that’s cool.

Jina Anne: Then on the design side, InVision already has it in their DSM tool, which is their Design System Manager tool. The last I looked at it, it was just colors and typography, but I do know when I… I talked to Evan, who is one of the main folks behind that product. He did tell me other things like spacing should be coming into play, if it’s not already. I haven’t looked at it super recently. I know there are newer tools that are really catching my eye, like modules and interplay. Both of those are code-driven design tools.

Jina Anne: Then I’ve been told that it’s supposed to come into some of the stuff that Figma and Adobe are doing, so I’m not sure if I’m revealing secrets. I don’t think I am. I think it’s all stuff they’ve talked about publicly. But, yeah, I’m really excited because I think while it was something that we were doing really just making our design system work easier, it’s kind of almost accidentally created a path for bringing design tools and code cluster together. That’s really exciting to me.

Drew: The makers of these various tools, are they working with the design tokens community group?

Jina Anne: Yeah, a lot of them have joined. Since I’m a chair member, I get to see by email, everybody who joins. It sends me a notice. What’s cool is not only just seeing all these design tool people joining, but also seeing big companies. I saw like Google and Salesforce and all that, so it’s really exciting. Because I think it shows that this really matters to where a lot of people are doing on a large scale and small scale and that’s pretty cool.

Drew: So, if I was sort of listening to this and thinking about my own projects, thinking, “Ah, yes, design tokens are absolutely the answer to all these problems that I’m having,” where would I go to find out more to start learning and start maybe using design tokens?

Jina Anne: It’s a really good question. There are a few articles and I can send you some links to include with this, but I think one of the first articles, which I wish I had written, but Nathan Curtis wrote and that he actually kind of helped bring attention to them. I think he inspired a lot of people to start using them, so he kind of discusses what they are and how to use them, his recommended way.

Jina Anne: I don’t like the title of this next article I’m going to mention, but it’s called Design Tokens for Dummies. I’m not a fan of using that terminology, but it is a pretty well thought-through article that goes to pretty much everything about them. There was a CSS Tricks article by Robin Randall recently that just explains really what they are. I did a All You Can Learn Library session for Jared Spool a while back, but it is a membership-based thing so you would have to have access to that to see it. I know there’s been a lot of presentations and stuff, but there’s not like an official book to it yet. But that’s perhaps something I’m working on. It’s like one of two books I’m working on, actually.

Drew: So, if I’m a toolmaker or I work for maybe a big organization that’s having these sorts of problems and they’ve got some ideas about maybe contributing to the process of designing how the standard works, is the design tokens community group something that I could get involved in?

Jina Anne: Absolutely. I think you’ll want a GitHub because that’s where all of the public discussions and notes and things are happening. Then on the W3C community group website, you can create an account there. Having that account enables you to join other community groups as well. But then, yeah, at that point once you’ve created your account there and… I think it asks if you have any affiliations, like if you work for a big company or anything like that, just so it’s transparent, like if you have any, I wouldn’t say necessarily bias, but like a certain interest. It just helps everybody understand where you’re coming from. Anyway, at that point, yeah, you join and you’re pretty much in.

Drew: It’s quite an open process then.

Jina Anne: Yeah.

Drew: What’s in the future for design tokens? What’s coming down the line?

Jina Anne: I’m really excited about what’s going on with the community group. Kaelig’s been doing most of the leading of it. He’s the co-chair with me and I really love seeing his passion behind this. My particular interests in this are really around the education of it. So, kind of similarly to the work I’ve been doing with the Sass community, I kind of want to do a little bit of that for the design token community, like talk through how to educate people on what this is and not just make it an API doc, but also like where to get started, how to get into this. That’s something I’m interested in project-wise.

Jina Anne: I’m also really keen to see where this evolves, especially with all these design tool companies getting involved. Then a lot of people mostly think about design tokens as a visual abstraction, but really what it came from was the same technology that you used for localizing content. You wrap things in strings and then you can pass through different stuff, so bringing it back to its roots. I’d love to see the application of this apply in different ways, like interactions and content. I’m not really super keen on AR/VR-type stuff, but how does it maybe manifest there? Yeah, really just seeing it kind of go beyond just like the visual layer of what we see.

Drew: I guess that’s the beauty of having an open process like the W3C community group, is that people who do have specialisms in things like AR and VR can contribute to the conversation and bring their expertise to it as well.

Jina Anne: Absolutely.

Drew: I’ve been learning a lot about design tokens today. What have you been learning about lately?

Jina Anne: I’m always trying to learn something, but I’ve actually been occasionally taking some cocktail classes. Yeah. I’m not really with the interest of becoming a bartender, but more of just having an appreciation for cocktails. What’s cool about these classes is they’re beyond just making cocktails. They actually talk about business practices and ethical practices, the hygiene of your bar, all sorts of stuff like that, so it’s been really fascinating because I think I have like this weird fantasy of one-day leaving tech and maybe going into that. Let’s see.

Drew: Do you have a favorite cocktail?

Jina Anne: Manhattan.

Drew: It’s good. It’s good.

Jina Anne: Yeah.

Drew: You can’t go wrong with a Manhattan.

Jina Anne: I have been ordering a lot of Old Fashioneds lately so that would probably be number two.

Drew: Do you have a favorite bourbon?

Jina Anne: Ooh. The first one that came to mind is Angel’s Envy. It’s like finished in port barrels that have kind of this slightly port-like essence to it. Their rye is really good, too. It’s like finished in rum barrels, so it almost has like a banana bread-like flavor to it.

Drew: This is a direction I wasn’t expecting to go in today.

Jina Anne: Yeah.

Drew: Was there anything else you’d like to talk about design tokens?

Jina Anne: My take is, just like with design systems, people are going to use them in different ways and also there might be people out there that don’t even need to use this. If you just have like an editorial website that is pretty straightforward, maybe all you really need are CSS variables and that’s it. There’s no need to over-engineer things.

Jina Anne: This is really more for people that really need to scale or if you have a theming context then maybe. But, yeah, it’s really not meant for everyone. So, just because it’s becoming kind of a hot thing to talk about, you might not need to even bother with it.

Drew: If you, dear listener, would like to hear more from Jina, you can follow her on Twitter where she’s @Jina, or find her and all her projects on the web at Thanks for joining us today, Jina. Do you have any parting words?

Jina Anne: Design systems are for people.

(dm, ra, il)
Categories: Design

Abstracting WordPress Code To Reuse With Other CMSs: Concepts (Part 1)

19 hours 40 min ago
Abstracting WordPress Code To Reuse With Other CMSs: Concepts (Part 1) Abstracting WordPress Code To Reuse With Other CMSs: Concepts (Part 1) Leonardo Losoviz 2019-11-18T12:00:00+00:00 2019-11-18T12:47:28+00:00

Making code that is agnostic of the CMS or framework has several benefits. For instance, through its new content editor Gutenberg, WordPress enables to code components which can be used for other CMSs and frameworks too, such as for Drupal and for Laravel. However, Gutenberg’s emphasis on re-utilization of code is focused on the client-side code of the component (JavaScript and CSS); concerning the component’s backend code (such as the provision of APIs that feed data to the component) there is no pre-established consideration.

Since these CMSs and frameworks (WordPress, Drupal, Laravel) all run on PHP, making their PHP code re-usable too will make it easier to run our components on all these different platforms. As another example, if we ever decide to replace our CMS with another one (as has recently happened that many people decried WordPress after its introduction of Gutenberg), having the application code be agnostic from the CMS simplifies matters: The more CMS-agnostic our application code is, the less effort will be required to port it to other platforms.

Starting with application code built for a specific CMS, the process of transforming it to CMS-agnostic is what, in this article, I will call “abstracting code”. The more abstract the code is, the more it can be re-used to work with whichever CMS.

Making the application completely CMS-agnostic is very tough though — even possibly impossible — since sooner or later it will need to depend on the specific CMS’s opinionatedness. Then, instead of attempting to achieve 100% code reusability, our goal must simply be to maximize the amount of code that is CMS-agnostic to make it reusable across different CMSs or frameworks (for the context of this article, these 2 terms will be used interchangeably). Then, migrating the application to a different framework will be not without pain, but at least it will be as painless as possible.

The solution to this challenge concerns the architecture of our application: We must keep the core of the application cleanly decoupled from the specifics of the underlying framework, by coding against interfaces instead of implementations. Doing so will grant additional benefits to our codebase: We can then focus our attention almost exclusively on the business logic (which is the real essence and purpose of the application), causing the code to become more understandable and less muddled with the limitations imposed by the particular CMS.

This article is composed of 2 parts: In this first part we will conceptualize and design the solution for abstracting the code from a WordPress site, and on the 2nd part we will implement it. The objective shall be to keep the code ready to be used with Symfony components, Laravel framework, and October CMS.

Code Against Interfaces, Rely On Composer, Benefit From Dependency Injection

The design of our architecture will be based on the following pillars:

  1. Code against interfaces, not implementations.
  2. Create packages, distribute them through Composer.
  3. Dependency Injection to glue all parts together.

Let’s analyze them one by one.

Code Against Interfaces, Not Implementations

Coding against interfaces is the practice of interacting with a certain piece of code through a contract. A contract, which is set up through an interface from our programming language (PHP in our case since we are dealing with WordPress), establishes the intent of certain functionality, by explicitly stating what functions are available, what inputs are expected for each function, and what each function will return, and it is not concerned with how the functionality must be implemented. Then, our application can be cleanly decoupled from a specific implementation, not needing to know how its internals work, and being able to change to another implementation at any time without having to drastically change code. For instance, our application can store data by interacting with an interface called DataStoreInterface instead of any of its implementations, such as instances of classes DatabaseDataStore or FilesystemDataStore.

In the context of WordPress, this implies that — by the end of the abstraction — no WordPress code will be referenced directly, and WordPress itself will simply be a service provider for all the functions that our application needs. As a consequence, we must consider WordPress as a dependency of the application, and not as the application itself.

Contracts and their implementations can be added to packages distributed through Composer and glued together into the application through dependency injection which are the items we will analyze next.

Create Packages, Distribute Them Through Composer

Remember this: Composer is your friend! This tool, a package manager for PHP, allows any PHP application to easily retrieve packages (i.e. code) from any repository and install them as dependencies.

Note: I have already described how we can use Composer together with WordPress in a previous article I wrote earlier this year.

Composer is itself CMS-agnostic, so it can be used for building any PHP application. Packages distributed through Composer, though, may be CMS-agnostic or not. Therefore, our application should depend on CMS-agnostic packages (which will work for any CMS) as much as possible, and when not possible, depend on the corresponding package that works for our specific CMS.

This strategy can be used to code against contracts, as explained earlier on. The packages for our application can be divided into two types: CMS-agnostic and CMS-specific ones. The CMS-agnostic package will contain all the contracts and all generic code, and the application will exclusively interact with these packages. For each CMS-agnostic package containing contracts, we must also create a CMS-specific package containing the implementation of the contracts for the required CMS, which is set into the application by means of dependency injection (which we’ll analyze below).

For example, to implement an API to retrieve posts, we create a CMS-agnostic package called “Posts”, with contract PostAPIInterface containing function getPosts, like this:

interface PostAPIInterface { public function getPosts($args); }

This function can be resolved for WordPress through a package called “Posts for WordPress”, which resolves the contract through a class WPPostAPI, implementing function getPosts to simply execute WordPress function get_posts, like this:

class WPPostAPI implements PostAPIInterface { public function getPosts($args) { return get_posts($args); } }

If we ever need to port our application from WordPress to another CMS, we must only implement the corresponding CMS-specific package for the new CMS (e.g. “Posts for October CMS”) and update the dependency injection configuration matching contracts to implementations, and that’s it!

Note: It is a good practice to create packages that only define contracts and nothing else. This way, it is easy for implementers to know exactly what must be implemented.

Dependency Injection To Glue All Parts Together

Dependency injection is a technique that allows declaring which object from the CMS-specific package (aka the “service provider”) is implementing which interface from the CMS-agnostic package (aka the “contract”), thus gluing all parts of the application together in a loosely-coupled manner.

Different CMSs or frameworks may already ship with their own implementation of a dependency injection component. For instance, whereas WordPress doesn’t have any, both Symfony and Laravel have their own solutions: DependencyInjection component and Service Container respectively.

Ideally, we should keep our application free from choosing a specific dependency injection solution, and leave it to the CMS to provide for this. However, dependency injection must be used also to bind together generic contracts and services, and not only those depending on the CMS (for instance, a contract DataStoreInterface, resolved through service provider FilesystemDataStore, may be completely unrelated to the underlying CMS). In addition, a very simple application that does not require an underlying CMS will still benefit from dependency injection. Hence, we are compelled to choose a specific solution for dependency injection.

Note: When choosing a tool or library, prioritize those ones which implement the corresponding PHP Standards Recommendation (in our case, we are interested in PSR-11), so they can be replaced without affecting the application code as much as possible (in practice, each solution will most likely have a custom initialization, so some re-writing of application code may be unavoidable).

Choosing The Dependency Injection Component

For my application, I have decided to use Symfony’s DependencyInjection component which, among other great features, can be set-up through YAML and XML configuration files, and it supports autowiring, which automatically resolves how different services are injected into one another, greatly reducing the amount of configuration needed.

For instance, a service Cache implementing a contract CacheInterface, like this one:

namespace MyPackage\MyProject; class Cache implements CacheInterface { private $cacheItemPool; private $hooksAPI; public function __construct( CacheItemPoolInterface $cacheItemPool, HooksAPIInterface $hooksAPI ) { $this->cacheItemPool = $cacheItemPool; $this->hooksAPI = $hooksAPI; } // ... }

… can be set as the default service provider through the following services.yaml configuration file:

services: _defaults: bind: MyPackage\MyProject\HooksAPIInterface: '@hooks_api' hooks_api: class: \MyPackage\MyProject\ContractImplementations\HooksAPI cache: class: \MyPackage\MyProject\Cache public: true arguments: $cacheItemPool: '@cache_item_pool' cache_item_pool: class: \Symfony\Component\Cache\Adapter\FilesystemAdapter

As it can be observed, class cache requires two parameters in its constructor, and these are resolved and provided by the dependency injection component based on the configuration. In this case, while parameter $cacheItemPool is manually set, parameter $hooksAPI is automatically resolved through type-hinting (i.e. matching the expected parameter’s type, with the service that resolves that type). Autowiring thus helps reduce the amount of configuration required to glue the services and their implementations together.

Make Your Packages As Granular As Possible

Each package must be as granular as possible, dealing with a specific objective, and containing no more or less code than is needed. This is by itself a good practice in order to avoid creating bloated packages and establishing a modular architecture, however, it is mandatory when we do not know which CMS the application will run on. This is because different CMSs are based on different models, and it is not guaranteed that every objective can be satisfied by the CMS, or under what conditions. Keeping packages small and objective then enables to fulfill the required conditions in a progressive manner, or discard using this package only when its corresponding functionality can’t be satisfied by the CMS.

Let’s take an example: If we come from a WordPress mindset, we could initially assume that entities “posts” and “comments” will always be a part of the Content Management System, and we may include them under a package called “CMS core”. However, October CMS doesn’t ship with either posts or comments in its core functionality, and these are implemented through plugins. For the next iteration, we may decide to create a package to provide for these two entities, called “Posts and Comments”, or even “Posts” under the assumption that comments are dependent on posts and bundled with them. However, once again, the plugins in October CMS don’t implement these two together: There is a plugin implementing posts and another plugin implementing comments (which has a dependency on the posts plugin). Finally, our only option is to implement two separate packages: “Posts” and “Comments”, and assign a dependency from the latter to the former one.

Likewise, a post in WordPress contains post meta attributes (i.e. additional attributes to those defined in the database model) and we may assume that every CMS will support the same concept. However, we can’t guarantee that another CMS will provide this functionality and, even if it did, its implementation may be so different than that from WordPress that not the same operations could be applied to the meta attributes.

For example, both WordPress and October CMS have support for post meta attributes. However, whereas WordPress stores each post meta value as a row on a different database table than where the post is stored, October CMS stores all post meta values in a single entry as a serialized JSON object in a column from the post table. As a consequence, WordPress can fetch posts filtering data based on the meta value, but October CMS cannot. Hence, the package “Posts” must not include the functionality for post meta, which must then be implemented on its own package “Post Meta” (satisfiable by both WordPress and October CMS), and this package must not include functionality for querying the meta attributes when fetching posts, which must then be implemented on its own package “Post Meta Query” (satisfiable only by WordPress).

Identifying Elements That Need To Be Abstracted

We must now identify all the pieces of code and concepts from a WordPress application that need be abstracted for it to run with any other CMS. Digging into an application of mine, I identified the following items:

  • accessing functions
  • function names
  • function parameters
  • states (and other constant values)
  • CMS helper functions
  • user permissions
  • application options
  • database column names
  • errors
  • hooks
  • routing
  • object properties
  • global state
  • entity models (meta, post types, pages being posts, and taxonomies —tags and categories—)
  • translation
  • media

As long as it is, this list is not yet complete. There are many other items that need abstraction, which I will not presently cover. Such items include dealing with the location of assets (some framework may require to place image/font/JavaScript/CSS/etc. files on a specific directory) and CLI commands (WordPress has WP-CLI, Symfony has the console component, and Laravel has Artisan, and there are commands for each of these which could be unified).

In the next (and final) part of this series of articles, we will proceed to implement the abstraction for all the items identified above.

Evaluating When It Makes Sense To Abstract The Application

Abstracting an application is not difficult, but, as shall be observed in the next article, it involves plenty of work, so we must consider carefully if we really need it or not. Let’s consider the advantages and disadvantages of abstracting the application’s code:

  • The effort required to port our application to other platforms is greatly reduced.
  • Because the code reflects our business logic and not the opinionatedness of the CMS, it is more understandable.
  • The application is naturally organized through packages which provide progressive enhancement of functionalities.
  • Extra ongoing work.
  • Code becomes more verbose.
  • Longer execution time from added layers of code.

There is no magic way to determine if we’ll be better off by abstracting our application code. However, as a rule of thumb, I’ll propose the following approach:

Concerning a new project, it makes sense to establish an agnostic architecture, because the required extra effort is manageable, and the advantages make it well worth it; concerning an existing project, though, the one-time effort to abstract it could be very taxing, so we should analyze what is more expensive (in terms of time and energy): the one-time abstraction, or maintaining several codebases. Conclusion

Setting-up a CMS-agnostic architecture for our application can allow to port it to a different platform with minimal effort. The key ingredients of this architecture are to code against interfaces, distribute these through granular packages, implement them for a specific CMS on a separate package, and tie all parts together through dependency injection.

Other than a few exceptions (such as deciding to choose Symfony’s solution for dependency injection), this architecture attempts to impose no opinionatedness. The application code can then directly mirror the business logic, and not the limitations imposed by the CMS.

In the next part of this series, we will implement the code abstraction for a WordPress application.

(rb, dm, yk, il)
Categories: Design

Smashing Monthly Roundup: Community Resources And Favorite Posts

Fri, 11/15/2019 - 06:00
Smashing Monthly Roundup: Community Resources And Favorite Posts Smashing Monthly Roundup: Community Resources And Favorite Posts Iris Lješnjanin 2019-11-15T14:00:00+00:00 2019-11-15T17:06:32+00:00

On behalf of the Smashing team, welcome to another monthly update to keep you all in the loop about all things smashing. Join us as we share the latest news and highlight the things we have enjoyed reading over the past month.

Many of the included posts are sourced from the most popular links from our Smashing Newsletter. If you don’t get our newsletter yet, then sign up here to receive useful techniques and goodies (including a free eBook on accessibility)!

What’s New At Smashing?

The last SmashingConf of this year took place in New York, an event that got sold out a long way in advance and another one we’re all quite proud of. In case you missed out, our editor-in-chief Rachel Andrew summed up everything in a post with videos and photos of SmashingConf NY. You can find the slides of the talks over here, and even already grab your super early-bird ticket if you like!

Next, there’s a ’lil project that we’ve been meaning to launch for a quite a while, and it’s finally happening! We’re proud to have kicked off the Smashing Podcast, a bi-weekly podcast that is moderated by our dear friend Drew McLellan — make sure to subscribe and tune into any podcast player of your choice.

Last but not least, we’re excited and looking very much forward to the release of the upcoming Smashing book “Inclusive Components” written by Heydon Pickering on the whys and the hows, making accessibility more approachable and friendly for developers. Stay tuned!

Recommended Reading on Smashing Magazine

We publish a new article every day, and so if you’re not subscribed to our RSS feed or follow us on social media, you may miss out on some brilliant articles! Here are some that our readers seemed to enjoy and recommend further:

  • How To Stop Analysis Paralysis With Design” by Suzanne Scacca
    When it comes to putting our visitors on the spot, giving them too many options hurts their decision-making ability along with how they feel about the experience as a whole.
  • What Newspapers Can Teach Us About Web Design” by Frederick O’Brien
    Before the home page, there was the front page. From the Gutenberg Principle to grid systems to above the fold, newspapers teach us much about the foundations of web design.
  • Creating Online Environments That Work Well For Older Users” by Barry Rueger
    A significant part of the Internet-using population is aged 50 or older — including the people who invented it. Designers need to understand what older users need and why it’s not enough to just say, “I can read it, so what’s the problem?”
  • Writing A Multiplayer Text Adventure Engine In Node.js” by Fernando Doglio
    A 4-part series that takes you through step by step to help you create a text-adventure engine with Node.js.
Best Picks From Our Newsletter

We’ll be honest: Every second week, we struggle with keeping the Smashing Newsletter issues at a moderate length — there are just so many talented folks out there working on brilliant projects! So, without wanting to make this monthly update too long either, we’re shining the spotlight on the following projects:

Note: A thank you to Cosima Mielke for writing and preparing these posts!

Free Services For Developers

So many services out there offer free tiers, but they can be hard to find. Free For Developers wants to change that and lists software and other services that have free tiers for developers., a list of SaaS, PaaS and IaaS offerings that have free tiers of interest to devops and infradev.

The services included in the list are particularly interesting for System Administrators, DevOps Practitioners, and other infrastructure developers and cover everything from cloud providers and source code repos to testing, log management, payment integration, and a lot more. More than 500 people have contributed to this community project and you are welcome to submit your findings, too, of course. A handy resource for the bookmarks.

Git Command Cheatsheet

Do you know your git commands? While you probably know the most common ones by heart, there are always those commands that are easily forgotten because you don’t need them often. A concise refresher now comes from Rainer Selvet.

GitSheet, a dead simple git cheatsheet.

Described as a “dead simple git cheatsheet” by its creator, GitSheet lists git commands and what they do by topic. A nifty little feature: You can copy a command to your clipboard with just a click. Simple yet effective.

A Playground For Tinkering With Design Systems

You’re about to build a design system but don’t really know where or how to begin? Well, the Design System Playground might be a great place to get started.

Design System Playground, an open-source project built by John Polacek.

The playground offers a lot of room to tinker with different font and color combinations and, once you’re happy with your choices, it generates a design system that you can export and use in your projects right away. If the visual direction of your design isn’t clear yet, there’s also the option to use a preset theme or random choices to build upon.

Freebie: Mix-And-Match Illustrations

Illustrations are a fantastic way to breathe some life into a project. But not all of us have the skills to create them ourselves or the time or the budget to hire an illustrator. For these occasions, the mix-and-match illustration library which Leni Kauffman created, might come in handy.

Fresh Folk, a beautiful illustration library of people and objects created and designed by London-based illustrator Leni Kauffman.

Fresh Folk lets you combine poses, outfits, and skin tones into different characters. The library also includes background elements (e.g., tables, seating, lamps, plants) to create different settings — from office spaces to nature scenes. Free for personal and commercial projects.

Real-Time Visualization Of Tokyo’s Public Transport

A stunning 3D data visualization project comes from Akihiko Kusanagi: Mini Tokyo 3D displays Tokyo’s public transport system on a map in realtime.

Large preview, a real-time 3D digital map of Tokyo's public transport system.

You can follow along Tokyo’s trains moving through the city, with information on the train line, train number, next and previous stops, and possible delays. The data for this mammoth project is sourced from Open Data Challenge for Public Transportation in Tokyo which promotes the openness of public transportation data. Their aim is to make public transportation (which is considered to be the world’s most complicated) easier to navigate. Inspiring!

Vintage Science And Tech Ads

If you’ve got a sweet spot for vintage graphic design, here’s a very special goodie for you: a Flickr album with more than 1,400 science and tech ads from the 1950s and 60s.

Science and Tech Ads” (Flickr album), a random assortment of science ads collected from various science and tech magazines of the 50s and 60s.

The ads come from various science and tech magazines and are great examples of the modernist mid-century aesthetic — and a fascinating journey back to the times when the foundations of the technologies we take for granted today were being laid. Eye candy!

JavaScript Frameworks Security Report 2019

The folks at Snyk published their state of JavaScript frameworks security report for 2019. It investigates the state of security for the Angular and React ecosystems as well as security practices for the popular JavaScript frameworks Vue.js, Bootstrap, and jQuery.

JavaScript Frameworks Security Report 2019, a report that investigates the state of security for both the Angular and React ecosystems.

Given the fact that Angular and React both have their proponents with ongoing discussions whether one or the other is a true framework, the report doesn’t intend to venture into rivalries but reviews each of them as viable front-end ecosystem alternatives, while focusing on security risks and best practices and the differences between them. A must-read.

Designing Accessible Color Systems

Getting color contrast right is an essential part of making sure that not only people with visual impairments can easily use your product but also everyone else when they are in low-light environments or using older screens. However, if you’ve ever tried to create an accessible color system yourself, you probably know that this can be quite a challenge.

Designing Accessible Color Systems” written by Daryl Koopersmith and Wilson Miner.

The team at Stripe recently decided to tackle the challenge and redesign their existing color system. The benefits it should provide out of the box: pass accessibility guidelines, use clear and vibrant hues that users can easily distinguish from one another, and have a consistent visual weight without a color appearing to take priority over another. If you’re curious to find out more about their approach, their blog post will give you valuable insights.

Digital Wellbeing Experiments

Everyone has a different relationship with their phones, but we all have something in common: There are always those moments when it feels that phones distract from life rather than improve it — when having dinner with friends and everyone checks their incoming notifications, for example.

Digital Wellbeing Experiments”, a showcase of ideas and tools that help people find a better balance with technology.

With their Digital Wellbeing Experiments, Google now showcases ideas and tools that help people find a better balance with technology and inspire designers and developers to consider digital wellbeing in everything they design and build. There are experiments that let you switch off from technology as a group, for example, stay focused by getting the right apps at the right times, or take the most important things with you on a printed “paper phone”. The code for the experiments is open-source, and if you have an idea for a digital wellbeing experiment, the Hack Pack will help you bring it to life.

Recursive: A Free Highly-Flexible Variable Font

A font that gives you typographic control over five stylistic axes and can go from Sans to Mono? The variable font Recursive makes it possible, offering an entirely new level of flexibility.

Recursive Font, a typographic palette for vibrant code and UI.

Taking full advantage of variable font technology, Recursive enables you to choose from a wide range of predefined styles or dial in exactly what you want for each of its axes. Inspiration came from single-stroke casual signpainting to give the font a flexible and energetic look, making it a great fit for data-rich-apps, technical documentation, code editors, and much more. Please note that Recursive is still under active development and will soon be available through Google Fonts. A beta version is already available.

Open-Source Tutorials For Learning GraphQL

GraphQL enables a client to specify exactly what data it needs from an API, so instead of multiple endpoints that return fixed data structures, a GraphQL server exposes a single endpoint and responds with precisely the data a client asked for. If you want to wrap your head around GraphQL, here are two great resources to get you started.

There are a number of open-source community maintained tutorials that will help you to move from the basics of GraphQL to building a real-time application in no time.

How to GraphQL is a free open-source tutorial to take your GraphQL skills from zero to production. Divided up into two parts, part one covers the core concepts of GraphQL while part two gives you a broader understanding of the GraphQL ecosystem. The other learning resource comes from the makers of the GraphQL engine Hasura: three open-source community-maintained tutorials (front-end, mobile, and back-end tutorials) teach you GraphQL to get you ready to build a real-time application in two hours.

Fixing Image Orientation

Image orientation on the web is, well, complicated. When Michael Scharnagl worked on a side project, he noticed that the images he uploaded to his server were shown in the wrong orientation. Now he wrote a blog post in which he dives deeper into the issue and how to fix it.

Image orientation on the web explained by Michael Scharnagl.

The reason for portrait images being displayed in landscape mode when they are embedded using <img> or background-image is the EXIF data for the image. How a browser deals with EXIF orientation depends on the browser, and there’s no cross-browser way to easily correct it either. Michael’s Node.js fix helps you correct the orientation. A handy little tip.

From Smashing With Love

A month can be a long time to stay on top of things, so please do subscribe to our bi-weekly newsletter and our podcast if you still haven’t. Each and every issue is written and edited with love and care. No third-party mailings or hidden advertising — promise!

You can also tune into our very own Smashing TV, and follow us on Twitter, Facebook as well as LinkedIn. Please do always feel free to reach out and share your projects with us! We love hearing from you!

Keep up the brilliant work, everyone! You’re smashing!

Smashing Newsletter

Upgrade your inbox and get our editors’ picks 2× a month — delivered right into your inbox. Earlier issues.

Your (smashing) email Subscribe → Useful tips for web designers. Sent 2× a month.
You can unsubscribe any time — obviously. (cm, vf, ra, il)
Categories: Design

Become An HTML Email Geek With These Videos From Rémi Parmentier

Thu, 11/14/2019 - 04:00
Become An HTML Email Geek With These Videos From Rémi Parmentier Become An HTML Email Geek With These Videos From Rémi Parmentier Rachel Andrew 2019-11-14T12:00:00+00:00 2019-11-14T13:46:42+00:00

Creating an HTML email can feel like stepping back a few years as a web developer. All of our new layout functionality is unavailable to us &mdasj; email clients render the same layout in completely different ways. Just when we think we have it all fixed, another email client shows up with a new set of bugs.

Not too long ago, Rémi Parmentier, an HTML Email developer, ran a session with practical front-end techniques for building modern, cross-client emails. A few weeks later, he gave a wonderful talk at SmashingConf Freiburg highlighting some of the common struggles and shared useful strategies for avoiding problems in email development.

There was so much useful information contained in these sessions that we wanted to release them more widely — including the webinar transcript and references to slides and resources. If you have ever struggled with email development, these will give you a great starting point to understand why an email isn’t rendered properly, and how to squash those nasty bugs quickly.

If you enjoy learning from these videos, check out Smashing Membership. Starting from this month, we will be showing some of the live sessions we run every month to a wider audience — absolutely free of charge to view. However, if you’d like to join the discussion live and perhaps have your work reviewed by an expert, join Smashing Membership. For the price of one coffee a month, you can support the creation of more content like this.

Now get ready to learn everything you need to know about HTML email!

Webinar: HTML Email with Rémi Parmentier Resources And Transcript

Rémi Parmentier: Thanks, everyone, for coming to my presentation. My name is Rémi Parmentier. Some of you might know me from Twitter or from my blog under the nickname hteumeuleu. I’ve been doing HTML emails for as long as I’ve been working in this industry. For the past few years, I’ve started to give training in HTML emails as well I am spending a lot of time online on Slack, on Twitter, on forums to help people find solutions for their email problems. This gave me a pretty good view of most of the coding problems that people have and how to actually solve them. I started working on this email coding guidelines project this year. This was greatly inspired by some of the work that’s been done on the web about I think a decade ago.

Rémi Parmentier: About a decade ago, there was a lot of trends of web guidelines being shared by people from many different companies. First one was the most famous one was this code guide by Mark Otto, who was then working at Twitter. The point of the document was to share a lot of guidelines about how HTML and CSS should be coded within the company. There was a lot of good practices shared in this document, like which doctype you should use or to close your tag and such. I think this is really interesting to have.

Rémi Parmentier: In the email world, Ted Goas from Stack Overflow actually made a very similar document with a lot of content as well about how they’re building the emails at Stack Overflow. This really gave me the lust to make a similar document that everyone could share within their company or everyone could pick good practices for building HTML emails. We’re going to see a few of these best practices and you’ll be able to see the document afterwards online. Let’s start ahead.

Rémi Parmentier: The first thing that I usually share is to use the HTML5 doctype. Whenever I help people online of open HTML email, it makes me sad to see that a lot of people are still using HTML4 doctype or XHTML 1. The first reason to use the HTML5 doctype is that it’s really nice. Actually, it’s very short. You can type it by hand, you can remember it, and that’s already a good reason to use it.

Rémi Parmentier: The most important reason to use the HTML5 doctype is that when an email is displayed in webmail, our doctype is usually removed and we inherit from the webmail’s doctype. Most webmails use the HTML5 doctype, so even for you wish you could use HTML1 or HTML4 doctype, this won’t work because webmails will remove it.

Rémi Parmentier: I made this little illustration of how this actually works. On the left, you can see an email address coded. It’s got a style tag and it’s got a div and an H1 inside. What happens when a webmail like Gmail, for example, wants to display this content, it will pick the style tags and pick the content within the body, and it will prefix the styles, it will remove all the styles that it won’t support, and then it will include this inside the HTML of the actual webmail, because webmails are actually just HTML and CSS. This means that even if I use an HTML4 doctype, because Gmail uses HTML5 doctype, my code will be random thanks to that doctype. This is a good thing to have in mind.

Rémi Parmentier: I made this about this, about which doctype you should use in HTML emails, about three years ago already, but what I saw back then was that most of the email clients already were using an HTML5 doctype. A few of them didn’t have a doctype at all, like on mobile apps sometimes, but a lot of them were on HTML5.

Rémi Parmentier: It’s important to know that you can end up on different doctypes because there can be differences. The first one is that HTML5 actually have spaces between images. If you slice some big image inside your email, you will see something like this if you try it with an HTML5 doctype.

Rémi Parmentier: Let me actually show you this with a little demo. Here, I have this … Oops, it’s the wrong one. Here I have this little demo of a T-Rex. It’s actually three images. Here with an HTML1 doctype, everything is working fine, but if I use an HTML5 doctype instead, boom, you have white lines appearing between each images.

Rémi Parmentier: Now, I’m not exactly sure why this happens, but I think it’s because when HTML5 upgraded, they cannot change some of the way that images are supposed to behave according to the specification, so now it looks more like a paragraph with text, so there are lines in between images.

Rémi Parmentier: Email Geeks have found very good solutions to the service. One of the solutions is to actually add a display block style to every images. Once you do this, it will remove the white lines between the images. Another solution to avoid this if you can’t use display block is to add a vertical align middle style and then you will remove these white lines as well.

Rémi Parmentier: This is a first quirk that you can encounter with HTML5 doctype, but there is another interesting case is that you can’t display block a table cell in WebKit without a doctype. This one is really interesting as well. I’ve got a table for this as well, which would be right here.

Rémi Parmentier: Here I’ve got a table with three little dinosaurs next to each others. Usually when we’ve got tables like this and we want to make our emails optimized for mobiles, what we can do is apply the display block to our TDs and then they will stack on each others like this.

Rémi Parmentier: As we can see here, we have an HTML5 doctype. This is working fine, but if I would ever end up in an image client that will remove the doctype, then this won’t work anymore in WebKit. As you can see now, it’s back to the regular pattern display.

Rémi Parmentier: I think this has to do with legacy websites and quirk modes and all of these things, but one solution that was found by the email community is to actually use TH tags instead of TD. If I remove every TD here by TH, you can see that, here, even without a doctype, it’s working again. This is some kind of the quirks that you have to deal with in HTML emails because of not only email clients behave but also rendering engines like WebKit here.

Rémi Parmentier: The second best practice I’d want to share with you today is to use the lang attributes. The lang attribute in HTML is to define the language of your document. This is very important for accessibility, and mostly this is because accessibility tools like screen readers will be able to pick the right voice for it.

Rémi Parmentier: Once again, let me show you a demo of this live, and hopefully it won’t crash. Here I have this very nice email from Mailchimp. As it was said before, I am French, so my computer is set in French. My screen reader is in French as well, so every time we’ll see some new content, it will try to read it in French. I will stop my screen reader now. You try to see when we’ll get to this paragraph and see how it will read it.

Rémi Parmentier: I know that I don’t really have a good English accent, but this is even worse than mine. If you don’t set the lang attributes, your content will be read on whatever default language is for your users. The quick phase here is to add the lang attributes, and then I can restart my screen reader.

Screenreader:: Mailchimp Presents has a new collection of original content made with entrepreneurs in mind. In recent months, we’ve rolled out documentaries, short-form series and podcasts that live only on Mailchimp. Today, we officially launch a platform.

Rémi Parmentier: As you can hear, even for my screen reader, and my system is still set in French, once the screen reader is actually on HTML contents, it will use another voice, an English voice there, to read the content which makes the experience much, much better here.

Rémi Parmentier: One small difference that we have in HTML emails with the lang attribute is that, just like for the doctype, the doctype might not be picked up by webmails, because webmails will only take just styles and the content of the body. It’s usually a good practice to add the lang attribute as well on the wrapper that you have on your content inside your body, so you’ll make sure that this will get picked by webmails as well.

Rémi Parmentier: Now a third best practice that I like is to actually use styles over HTML attributes. This is really something that people hate about HTML emails because they feel that they have to use all the HTML attributes, they have to use all code, and this makes emails look very different from the web, but there is really no reason for this at all unless you need to support very old email clients like Lotus Notes 6 or similar.

Rémi Parmentier: In this example here, in the first example, you can see I’ve used valign, align and bgcolor attributes in HTML, but all of those can be very easily and robustly replaced by the corresponding styles. Here I only have one style attribute and inside I have the vertical align CSS property, text align and background color.

Rémi Parmentier: One reason I like to do this is because it makes go cleaner and more readable. All your presentational properties are grouped in a single style attribute instead of being all over the place with valign, align and all the stuff. This makes it, in my opinion, very, very better to read and to maintain.

Rémi Parmentier: There’s another reason I like to use styles over attributes is that it helps taking over email clients’ own styles. For example, on the French webmail of Orange, the webmail’s UI actually has a CSS that has a rule that sets every TD to vertical align top. Because of this rule, if you were to use only HTML attributes like valign=middle, the CSS role from the webmail would override with the HTML attributes because this is how the cascade works in HTML and CSS.

Rémi Parmentier: Instead, if we use an inline style with a vertical align property on the TD here, well, this style will take over the webmail style because inline styles are more important than external style sheets. Using styles over attributes is also a good way to fight other email clients’ and webmails’ default styles.

Rémi Parmentier: There are a few exceptions to the attributes that I still use. The first exceptions is to center a table in Outlook 2007 to 2019 on Windows, because as Scott said in the introduction, Outlook uses Word as a rendering engine in those versions and it’s not really good at understanding CSS, at least for some properties.

Rémi Parmentier: For example, here, it would understand the margin properties for pixel values, but it wouldn’t understand the margin zero auto value to center a table. We still need the align=center attribute to center elements and data, especially in Outlook, but we no longer need to use which attributes as in the first example here. This can be replaced by the width style instead.

Rémi Parmentier: Now other exception in Outlook as well is when you want to define a fluid image width. In the first example, I use a width attribute with 100% value. The thing is that Outlook actually doesn’t deal with percentage width for images the same way as it should be in CSS.

Rémi Parmentier: The percentage in Outlook is actually matching the physical image size and not the parent size in the HTML. If you’ve got an image that’s 600-pixel wide and you use a width=50%, then your image will actually be 300 pixels no matter what the size of your parent in HTML is.

Rémi Parmentier: Usually, to avoid any quirks with this is then I always define a fixed width in pixels for Outlook using the width attribute in HTML, and then using a style, I use a width with 100%. Outlook will only pick the attribute value here and not the style value.

Rémi Parmentier: Then, another exception I have when I use styles over attributes is to reset the default styles of the table. By default, the HTML tables have borders and padding inside and cells, et cetera. The proper way to do this in CSS is to set border zero, border spacing zero, our padding is zero, our border is zero, the first ones on the table, and expanding your border actually for each cell of your table.

Rémi Parmentier: This is pretty much why I don’t really like to do it the CSS way because you need to repeat the padding and border for every TD of your table, while if you use the attributes, you only need to use them on the table, and then you’re all set for any … no matter on any cells you have inside your table. This is probably something I will change my mind in a few years maybe, I hope, but for now, I’m still used and I prefer using the attribute way for resetting default styles on tables.

Rémi Parmentier: Now another best practice I’d like to share is, do not split the visuals. This was actually a very common practice maybe a decade ago. When we had large images, it was always better, at least it was always shared that you should split it to make download faster and things like that, but this is not true today.

Rémi Parmentier: Not splitting visual actually has a lot of benefits. The first one is that it’s easier to maintain. If you have a big visual in your email and it’s Friday night and your project manager comes at you and asks you to change it at the last minute, well, you don’t have to open Photoshop and slice your images again and where you’ve got everything. You can just replace that image and you’re done.

Rémi Parmentier: It’s also better for accessibility because you have a single image, you have a single element, so a single alt attribute. This is simpler and better for accessibility. One thing it’s also better for is for web performance, because downloading 100 kilobytes image is theoretically faster than downloading five image of 20 kilobytes.

Rémi Parmentier: That’s because for each image of 20 kilobytes, the request to the server needs to be made and we need to wait the answer five times. Even for the really small micro-transactions between the client and the server, this add up the more image you have, and it can slow down the download of your email image, so this is something to avoid.

Rémi Parmentier: Next, on the WebKit, there’s also a very weird behavior. Whenever you use a CSS transform on sliced images, WebKit will have very thin lines between split images. I would just show you a demo of this as well. Back to my first T-Rex image here, if I add a small transform here that will scale the image, here you can see that at this ratio, there are very small lines that appear within each slices of my image.

Rémi Parmentier: This is really due to WebKit not handling well the way they should scaled images like this. Maybe there’s a node size somewhere and it doesn’t compute properly, so you end up with small hair lines like this. Yes, the best practice here is to avoid to split your visuals.

Rémi Parmentier: This is actually something that will happen inside email clients because in, for example, if your email is bigger than the actual view of emails inside the clients, then your email will be resized using a CSS transform to feed the view port of the email client. This is something that you should be wary of.

Rémi Parmentier: Finally about splitting visual, I always try not to do it because this kind of things happens. This is something that was shared on Reddit almost 10 years ago. This is an email by LinkedIn and the face of this young lady, it was cut in half, maybe because some text was longer than expected or maybe because here the user chose to set up his email client with a bigger font than expected, so all kind of things can happen inside email clients, just like on the web. If you want to avoid these kind of strange situations, just don’t split visuals.

Rémi Parmentier: Next, this is a big one. This is tables for layouts. This surely is the most common thing that people think about when they think about HTML emails. It always annoys because we mostly don’t really need tables for layouts, except for one email client, and that is the Outlooks on Windows from 2007 to the latest 2019 version.

Rémi Parmentier: The reason of that, as we said before, is because all of those versions of Outlooks use Word as a rendering engine. Word is not really good in interpreting HTML and CSS. There is this documentation online about what it should be capable of, but it’s pretty hard to read and to make sense of, so I try to make this diagram to actually make sense of it.

Rémi Parmentier: From this documentation, what it says is that CSS supports in Outlook will actually vary from which elements you use CSS on. It will be different in body and span than in div and p and then all the other supported HTML tags.

Rémi Parmentier: First, if you have a body and span, you can only use what Microsoft calls Core CSS properties. That’s the color property, the font, text align and background color property. On the body element and the span element, you can only use those four CSS properties.

Rémi Parmentier: Then, on divs and paragraphs, you can use all those four properties from the Core level, but you can also use two new properties from what Microsoft calls the Coreextended level. In this level, you have two new properties, the text indent and margin properties.

Rémi Parmentier: Then, for all the other tags, you can use properties of the two previous levels, and you have what Microsoft calls the Full CSS support with many more CSS properties, but I think the most interesting are the width, height, padding, border and this kind of properties for defining elements.

Rémi Parmentier: This means here that if you want to use width and height properties and make it work in Outlook, you won’t be able to do this on a div because div only support Coreextended and Core CSS properties. You will need to use tables for those CSS properties, and the same thing for padding and border.

Rémi Parmentier: I usually narrow it down to the few following guidelines to use tables. I try to only use a table when I want to set a fixed width on an element. If I need an element to be a certain width, then I will use a table and define the width from that table.

Rémi Parmentier: Also, if I want to set two block elements side by side, because even Outlook doesn’t really support any advanced CSS layout property, so even float is not really well-supported, so if you need to have two elements side by side, then as you make a table with two cells, and those two elements will be next to each others then. Then I use tables whenever I need to set a padding, a background color or border style. This make it very reliant, very robust to use a table for those styles only.

Rémi Parmentier: Now a problem with tables is something we’ve learned in the way a long time ago is that tables are not made for presentation. They are made for actual data tables. This can be very problematic for screen readers especially. In order to improve accessibility here, we will use the role=presentation attribute whenever we will make a layout table.

Rémi Parmentier: Let me show you a quick example of how this will change the way your email is interpreted by a screen reader. I will take a new demo here. I’ve got this email from Jacadi, which is a French children clothing brand. They have this table here with different sizes of products. This is actually a table inside the code. I’ve pre-recorded a video here to show you how this is read by a screen reader.

Screenreader: Counting pairs, web content. Blank, blank, blank. Table 1 column. Nine rows. Blank. Column 1 of 1. Row 2. Nine Level 2 tables, seven columns. One row, Column 1 of 1. Blank. Column 3 of 7. Blank. Column 4 of 7. Blank. Column 5 of 7. Blank. Column 7 of 7. End of table. Row 3 of 9, blank. Column 1 of 1. Row 4 of 9, Row 2 table, seven columns, one blank. Column 1 of 7. Blank. Blank. End of table. Row 5 of 9, blank. Row 6 of 9, blank. Column, blank, blank, column end of table. Row 7 of 9, blank. Row 8 of 9 Row 2 table, blank. Column 1, blank. Column end of table. Row 9 of 9 blank. Column end of table.

Rémi Parmentier: This is terrible. This is so annoying. Now let’s see how we can fix these cells. The way we can fix this is by adding the role=presentation attributes. This is not something that it reads from tables to tables, so we need to add this attribute whenever we’ll have a new table. We have a few nested tables here, so we’ll add a few. Here is how the results sound.

Screenreader: Blank. Blank. Voice-over off.

Rémi Parmentier: This is so much better. This is so much smoother and it makes for much nicer experience. I hope this convinced you that you should always use as less tables as you can, but if you do, use role=presentation attributes on those tables.

Rémi Parmentier: Now, one step that we can take even further is that since tables are mostly for Outlook, we can use conditional comments to make those tables only visible on Outlook. Conditional comments are actually something that was available in Internet Explorer as well until I think I9. With these, if MSOs are in text, we can tell the borders that all the following contents within that conditional comment will be available only for MSO clients, so that’s mostly Outlook.

Rémi Parmentier: Then, between those opening and closing tables comments, we can have a div with a role or stuff that will come just like for a regular web border, although webmails will pick the div and Outlook will pick the table. This is video how I got most of my emails.

Rémi Parmentier: Now another small good practice to have is to use margin or padding for spacing. This is mostly to avoid empty containers, empty cells like this where we have a role within a cell with a height of 20 and then we have TDs with width of 20 to create margin all along with this content. I still see this done a lot, and this make your code really, really heavy. It’s less readable and it’s really bad in my opinion.

Rémi Parmentier: The proper way to do something like this would be to use a table as well if you want and have the padding style on the first TD, and then inside use margin to space tags between each others. This works again really well in every popular image client and in Outlook as well.

Rémi Parmentier: Now the small quirk that can happen in the Outlook and Windows is that there is the background color. If you use the background color on any of these elements with margin, it actually bleeds through the margin. Here’s an example where I should have a margin between the red background and blue background, but in Outlook, the margin is actually the same color of the background of that element. In those cases, then the solution is to maybe use another table and nest your content like this to space elements, but if you don’t use background, then margin is really safe even in Outlook.

Rémi Parmentier: Finally, this is perhaps my favorite recommendation. It’s to make it work without style tags. It’s not necessarily about having this raw HTML rendering, but thinking about progressive enhancements and graceful degradation and about how your emails will look without this guideline. This is something pretty unusual in cooperation of the web because it doesn’t happen on the web, but not having a style tag actually happens a lot on email clients.

Rémi Parmentier: First, not all email clients support style tags. Perhaps one of the most common example I see is Gmail on its mobile applications on iOS and Android lets you configure a third-party email address. You can use your Yahoo or address inside the Gmail app. If you do so, then every emails that you check won’t have support for style tags. This is what Email Geeks have nicknamed GANGA for Gmail apps with non-Gmail accounts. This is a very common occurrence that you can have.

Rémi Parmentier: Then you have a lot of cases for smaller or local or international email clients like SFR in France or Yandex and in Russia, et cetera. Even to this day, there are a lot of email clients that don’t support style tag, so if you want to make your code more robust, make sure that it can work without style tag.

Rémi Parmentier: Sometimes it’s also temporary. For example, in the past year or so, Gmail has had two days where style tags were completely removed from every email on every one of their email clients. We don’t know why this happened. There has been zero communication on that, but there’s a good chance that maybe they detected some kind of attacks that use certain styles, and so they needed to remove it very fastly and secure their users, so they removed style tag support for a few hours or almost a day. If you were to send a campaign that day, you were out of luck if your emails required style tags to work.

Rémi Parmentier: Sometimes also it’s contextual. For example, in Gmail, when you forward an email to someone, then you won’t have any style tags anymore, or when an email is viewed in its unclean version, you know when you have a view entire messaging at the bottom of your email because it was too long, if you view your email in that window, you won’t be able to have a style tag.

Rémi Parmentier: Then finally, sometimes it’s buggy. For example, in Yahoo Android in the app, the head is removed, so every style tag inside it are removed as well, but only the first head. We don’t really usually think as HTML documents are in multiple heads, but you can actually totally do this.

Rémi Parmentier: This has been pretty much a common practice now for a few years to deal with this bug in Yahoo. If you have a second head with your style with it, then it will work fine in Yahoo Android and in most email clients as well. We have just this empty head first so that Yahoo will strip it, and this will work.

Rémi Parmentier: Now, what I mean by making an email works is that the email should adjust its layer to any width without horizontal scroll and the email should reflect the branding of the sender. This can be colors often, this can be fonts or whatever, but make sure that it works without styles.

Rémi Parmentier: In order to do this, we can use inline styles. This is why most emails still use inline style, and I really recommend to do this for most of your styles. Make sure that the brand, the colors and everything can come up with just inline style.

Rémi Parmentier: Then, to tackle mobile emails to make sure that your emails can work fine from desktop to mobile, we have different solutions. The first one is to make your email fluid. I’ve got a little demo here as well, which I will show you right now.

Rémi Parmentier: This is an email that I’ve worked on almost four years ago for a French magazine, GEO. It’s got a lot of interesting things here. The first one is this grid here. If I try to resize it to make it responsive, you can see that it’s 100% fluid and it will scale accordingly to whatever the width for the image client is.

Rémi Parmentier: This works absolutely well without even a single style tag. This is just two tables on top, one for each lines, and we’ve got image inside it and the image are set with a fluid width, and so this works well enough even without style tags. This is good to have elements like this that can scale accordingly.

Rémi Parmentier: Now, this might not be the most optimal for every email, so another technique is to make your content hybrid. “Hee-breed,” or “hi-breed,” I’m not sure how you pronounce it, sorry for that, hybrid comes from the fact that you can still use media queries, but only as progressive enhancements, and then you need to make sure that your layout can fall back gracefully even without styles.

Rémi Parmentier: I would go back to this exact same email that I just showed you. A little bit lower here, we’ve got this gallery of user portraits. We can scale it as well. We have three columns here and then it will get on to two columns, and then only to one column.

Rémi Parmentier: The way this works here is using div width display in my block. We’ve got actually three divs like this next to each others and they all have a width of 33%. They will set so three can sit next to each others. They all have a minimum width of 140 pixels, so if there is no longer enough room to fit all those three elements because they’re in display inline block, they will naturally match even CSS flow down next to each others. This is a pretty good way to make it work like this.

Rémi Parmentier: I also use CSS and media queries here to make it a little bit more graceful when you have content here. If I disable the styles here, if I remove all of this, you can see that the layout has changed a little bit. We still have two columns, but they’re more stuck together. The layout still works appropriately where we can go from three to two to one layouts even without any styles, just with both div display and line blocks.

Rémi Parmentier: Then, perhaps the final, most popular way to make your emails work on mobiles is to make them mobile-first, to code them mobile-first. I will once again go back to that exact same email. You can see here that … Oops, it’s not fitting. I’ve got these two email columns next to each others. If I resize my window a little bit smaller, they will stack on each others.

Rémi Parmentier: Now because this is coded mobile-first, it means that this is actually the default layout for this zoom. On them, I use a min-width media query to change the layouts on desktop, on larger window sizes to make this work. If I remove all the styles here, just like I did before, you can see that now, our images are stacked on each others just like on mobile. This is what you’ll get when you code mobile-first. You get mostly your mobile view, but larger on desktop. This is really a lot of considerations to have when you’re coding emails for mobiles and for every email clients.

Rémi Parmentier: That’s pretty much it for me. All those recommendations, all those guidelines, you can find them online on GitHub, where I have these documents available. I really strongly encourage you really to share it within your colleagues and also to contribute to it.

Rémi Parmentier: If you think you have good recommendations that could apply to every emails you will code, feel free to share with me, feel free to contribute to this document as well. Hopefully you will have some questions. You can find me on Twitter or on my blog or you can send me an email as well if you have any questions after this session. Thank you.

Scott: Thank you very much, Rémi. “Re-my.” That was really very good. I’ve had a lot of questions about … Oh, hey, Vitaly.

Vitaly: Hello. Hello, Rémi. I’m so sorry about being late. Hello, everybody, dear Smashing members. I had a train delay and all. Scott, you wanted to say something? Sorry I interrupted you.

Scott: No. There was just two questions I was going to get out of the way. One was from Pawan, who’s a very, very active member of the Smashing membership. He is asking us, any thoughts on applying fonts consistently through HTML email?

Rémi Parmentier: Sorry, can you repeat?

Scott: Do you have any thoughts about applying fonts consistently through HTML email?

Rémi Parmentier: Yes. Well, for fonts, I usually encourage my clients to use web fonts in emails because it’s always better when you can have your own brand fonts. Now the thing to have in mind is that it won’t work everywhere. When using web fonts, especially, it almost works nowhere. It works in Apple Mail and in Thunderbird and maybe a few local email clients, but that’s really it. It doesn’t work in Gmail, it doesn’t work in Yahoo. If you can adapt to that, if that’s good for you, then go ahead and do it.

Rémi Parmentier: Now, the problem that you can have with web fonts like this is that if you try to use really funky fonts like Lobster or Pacifico on Google fonts, if it falls back to something like Arial or Helvetica, your email will definitely look very, very different. If you can use Montserrat and it falls back to Helvetica, that’s less a problem in my opinion. It really depends on the fonts you want to use and how much you are ready to not have this font in the cases where it won’t work.

Scott: That’s a really good point. There’s Zach Leatherman, who’s a very active member with Smashing and a presenter at SmashingConf, he’s done a lot of presentations about the fallback on fonts, so that’s interesting to make that correlation between email and web-based fonts.

Scott: Before I hand it over to Vitaly, my other question is, a lot of people are talking about interactive emails. There was actually, not this past SmashingConf, I believe the SmashingConf before, there was a presentation about interactive emails where you can actually complete an action just with one click of a button in an email, and mostly it’s based on AMP email. I was just curious, what do you know, what is AMP email and what’s the support for it currently?

Rémi Parmentier: AMP for Email is still something relatively new. It was announced by Google about a year ago, but it was only made available in Gmail desktop webmail about a few months ago, I think, in maybe April or something. AMP for Email is basically bringing the AMP Javascript framework to HTML email so that now inside Gmail, you can use interactive components like carousels or accordions, and you’ve got also, more interestingly, in my opinion, have live data.

Rémi Parmentier: If you’re selling clothes, for example, you can make sure that the clothes you’re presenting in your email are available in stock and are the ones in the best interest for your customer that’s viewing this email. This brings a lot of new customizations and possibilities for emails like that.

Rémi Parmentier: The thing is that it’s very still in its infancy and it mostly only works on Gmail desktops so far. It should come in on Gmail mobiles in the coming months, but then, there is also Yahoo and I think who said they were interested in implementing it.

Rémi Parmentier: Maybe this is something that will actually grab attention and go in the future. Yes, this is something I’m looking into and I’m really interested in. It’s still very hard to say if it will work and be successful, but there are a lot of interesting things in it.

Scott: Definitely. That falls back on what I was asking at the beginning before you started the presentation is, is there going to be some sort of standard that comes across for email clients? That’s my dream is that that will happen. On that note, Vitaly, I’m going to hand over to you for some questions.

Vitaly: Excellent. Thank you so much, Scott. Actually, Rémi, that was a brilliant presentation. Thank you so much. I learned-

Rémi Parmentier: Oh, thank you.

Vitaly: … a lot. I was a little bit not shocked, but in a way, I felt like it’s just wrong that we’re preaching these best practices for email which are not necessarily best practices full stop in 2019. It’s really about time that web standards have evolved.

Vitaly: We do have an open question from Pawan. Just before we do that, I have a couple, but one thing I wanted to know from somebody who’s so deeply motivated by the beauty and horror of email, I do have to find out, do you sleep well at night?

Rémi Parmentier: Oh, yes.

Vitaly: Excellent.

Rémi Parmentier: It depends because I have two small children, so not every night, but it’s not because of email.

Vitaly: Okay. The thing is, if you look back, let’s say, over the last, I don’t know, how many years have you been now in this madness?

Rémi Parmentier: Almost 15 years, but I really started digging into emails maybe five years ago, or maybe a little bit more, but yeah, about five years.

Vitaly: I’m curious, then, do you see that there has been a lot of progress in terms of email client supporting new features, broadening CSS support, Gmail, support of media queries and all? Do you see that the differences have been remarkable over the last five years or is it a very slow progress? Just so we can set expectations of what we should be expecting coming up next on the platform.

Rémi Parmentier: I would say both. It’s been both slow, but there has been progress. If you look back five years ago, five years ago, Gmail didn’t support media queries, and neither did Yahoo, I think, and neither did Media queries are a huge tool to make email works well on mobile. The simple fact that those emails were able to adapt and add this to their list of CSS properties and features supported is actually a very good thing.

Rémi Parmentier: Now, it’s always a bit frustrating because it definitely doesn’t move as fast as the web is moving nowadays where you can see new features added in Chrome or Firefox every week and new articles about it. Things are moving slowly for really unknown reasons. That’s perhaps the biggest problem of emails is that everything is really opaque.

Rémi Parmentier: We don’t know how things work within Gmail or within Outlook and we have a lot of advantages for the web, people from the Chrome team, from the Firefox team sharing all the new advances in their browsers, but this is not the case in email clients, and this is really perhaps the most frustrating thing is that if you see a bug, if you have a problem, you pretty much have no one to talk to.

Vitaly: It’s a little bit loud here. I’m just in a park, I promise. Pawan is wondering, do you have any thoughts on embedding HTML forms in emails? Is it a good idea or not?

Rémi Parmentier: It can work. This is actually something that’s done a lot by us in the presentation you mentioned. Mark Robbins was the godfather of interactive emails. A lot of people actually use form in emails. Just like everything, you just need to realize that this won’t work everywhere. You need to think about, what happens if my form doesn’t work? Do I show something different? Do I have a link that sets to a form on my website? This is perhaps the hardest part, when you try to think of advances in emails like that. Every time, you need to think about what happens if this doesn’t work and what will I show to the people when it won’t work.

Vitaly: That makes sense. Well, I have so many questions. If you do have a few minutes, I just wanted-

Rémi Parmentier: Yeah, sure.

Vitaly: Because just today, I had to send out a wonderful email to our wonderful Smashing subscribers. One thing that stuck with me, and I wasn’t really sure how to deal with it. Not every client who understand media queries. Gmail does. You will have the media rule and then it will be all fine, but then, for some reason, when we’re sending out with Mailchimp and we do inline styles, actually inline styles in the attributes, what happens is you have the inline styles say font size 21 pixel, let’s say, on H2. Then you have a media that overrides it with font size 28 or something else.

Vitaly: Am I correct to assume that it’s probably a good idea to avoid bang importance one way or the other, because it will override whatever you have in the inline styles? If you have a media rule, and then that media rule, you actually have font size 30 pixels importance, will it override inline styles or not in most-

Rémi Parmentier: Yeah, definitely importance will override inline style.

Vitaly: But then it’s included in the media rule, right? If a client doesn’t understand media, they wouldn’t know-

Rémi Parmentier: Yes, exactly. Yes, which is why you once again need to think what happens if media is not supported. There, your inline style will be picked up. Maybe you will need to have the mobile-first approach and have the smaller font size inline and then use a min-width media query to have the different font size on desktop.

Vitaly: Makes sense. When you start building, do you actually build mobile-first or do you build desktop-first?

Rémi Parmentier: Well, it really depends. As I just show in my last three examples between-

Vitaly: Oh, sorry, I must have missed a few things.

Rémi Parmentier: Yeah. Between the three examples or if we do mobile-first, these are different approaches that you can have and that makes sense, depending on the contents you have. Most of the time, I usually go mobile-first, but it really depends on how you want your fallback to display. Sometimes it makes sense to have more desktop layouts and sometimes it makes more sense to have more mobile layouts.

Vitaly: For testing, we’re using Mailchimp just to see how it looks in different clients, but Doug Working is asking, do you have any recommendations for tools to test email code to see how it looks in different email clients?

Rémi Parmentier: Yes. There are two very good and very popular email tools that will allow you to take screenshots of how your email render across many, many email clients. Those are Litmus and Email on Acid. They work really similarly for email testing.

Rémi Parmentier: You just import your code and you will get screenshots very fast of how your email looks. This is really how I recommend to test emails because, of course, you need to do some ports manually as well, but it’s so much faster when you have a tool like this that it’s really more professional and you will win a lot of time by working with tools like this.

Vitaly: But then, it basically takes screenshots that you have to analyze. If you discover something like a major bug, how do you debug? Any tools for remote debugging, so to say?

Rémi Parmentier: Yeah. Debugging is the hardest part. In webmails, actually, it’s pretty easy because since the webmail is just a webpage, you can fire up your browser inspector tools and inspect the webmail’s code. This is really something interesting to do. I encourage everyone to do it at least once in a while because you will see how the webmail transforms your code in ways that you maybe have never imagined, like prefixing and renaming the classes you can have in your code.

Rémi Parmentier: This is a good way to see if maybe an image client has removed some of your styles or maybe if you did a mistake somewhere. For webmail, this is the best way to debug. For other email clients like Outlook, this is really a try-and-retry approach where you just send a code, change something, resend the email-

Vitaly: It sounds like fun.

Rémi Parmentier: Yeah, this can be a bit irritating. With the experience, you do less and less of this, but yes, unfortunately, there are no developer to see in Outlook.

Vitaly: That makes sense. One more thing that actually came up as well, is it safe to use SVG in emails? Or if you’re having the same image, would you prefer to use SVG or would you recommend to stay away from SVG and use PNG or JPEG instead, or God forbid GIF?

Rémi Parmentier: GIFs are actually still very popular in email-

Vitaly: I know. I noticed.

Rémi Parmentier: … but there are actually no reason because PNG is just as well-supported as GIFs for that matter. Regarding SVGs, just as my previous answers, I will say do it if you can manage to make it fall back to something I think for other email clients.

Rémi Parmentier: I think SVG works very well in Apple Mail, in Mac OS and iOS. It might work in a few more email clients, but I don’t think it works well in webmails. If you can have a distant SVGs that you call maybe in … For example, if you use a picture tag, you can have a source with your SVG, so this will be picked up by Apple Mail. Inside this picture, you can have an image tag as a fallback with a regular PNG or JPEG. This will work in other email clients.

Rémi Parmentier: There are different ways to tackle this kind of things, but SVG is definitely not the first format for images that you were shown when you built emails, but this is definitely something you can use, even though it won’t work everywhere. If you can have the proper fallback, then go ahead and use it.

Vitaly: Willow Cheng is asking, would you have recommendation on design tools which could let you design and export email in HTML?

Rémi Parmentier: No. Unfortunately, nothing that I can think of right now. Because most of the time, tools that will offer you to generate your HTML from design tool will be really rubbish because it will be either completely outdated and not work well in most modern versions of email clients, so I would actually recommend to stay away from those tools. From design point of view, I’m not sure there are any tools that will let you export clean, proper HTML for emails.

Vitaly: That’s actually an answer I was expecting, to be honest. Maybe just one final question. I’m sure I’ll have more later, but I know you do also have family and all and it’s quite late as well, and I get to meet you in Freiburg, so this is just a couple of weeks from now, so at SmashingConf Freiburg. This is going to be exciting.

Vitaly: I do have a question, though, still. I remember for a while, maybe a year ago, maybe two years ago, I found these two resources which were great. One of them was The other is responsiveemailresources, or something like that, .com. One of them has gone away. It’s just down I think at this point, but I will also post the link later. Can you recommend some websites, resources where you can get copy-pastes almost email codes, snippets or something that you can reuse on a daily basis? I have heard that you might be working on something. Was I wrong?

Rémi Parmentier: I’m not sure, but I won’t talk about this for now, but it’s always [inaudible 01:04:56] snippets of codes that you can share because there are a lot of factors inside an email that can make your code behave differently. Every time there’s a tool that says it makes bulletproof backgrounds or bulletproof buttons, for example, you can always very easily, very shortly find email clients in which this doesn’t work properly. This is always a problem.

Rémi Parmentier: I remember the websites we were talking about, about responsive patterns, but I actually don’t know who were maintaining those. I don’t think they are ever really updated. As for websites, I can’t think of any right now. Maybe it will come later, that’s too bad, but the two things I will recommend is, if you’re into Twitter, follow the Email Geeks hashtag. That’s #emailgeeks, G-E-E-K-S. There are always a lot of people sharing good resources and the latest good articles that are always interesting.

Rémi Parmentier: The other thing I recommend is to join the Email Geeks at Slack channel. This is a really good community that’s growing a lot. There are all sorts of channels for marketing or for design or for code. People are really, really nice there and really always trying to help and almost available at any hours of the day, so this is incredible. If you look up for Email Geeks Slack on Google, you will see a subscription page that you can join. I hope you can join and just say “Hi” if you come.

Vitaly: Just one final, just the really, really last one, and then I’ll let you go. Sorry, excuse me if you mentioned it already in the session, but I’m wondering, as of today, as of 2019, looking at the best practices and the email clients, what are the baseline where you would say, let’s support this kind of client?

Vitaly: Because at this point, when we think about a 8, sometimes you obviously want to search something accessible to a 8, but you’re not going to optimize for a 8. We’re getting to the point where some companies can actually start dropping a 9 in the same way, but again, we’re quite far away yet.

Vitaly: When it comes to email clients, is Outlook 2013 still a thing? I remember the big update that Outlook brought in 2013 changed a lot of things in email, if I remember correctly. As of today, when we look into the landscape of email clients, what is the baseline we absolutely have to support at least?

Rémi Parmentier: I think the-

Vitaly: To support.

Rémi Parmentier: The others’ basis is Outlook 2007, because this is something actually pretty annoying is that this is used in a lot of big companies, and those big companies don’t pays new license for new versions of Outlook every year and they pay for a decade or so. There are still quite a lot of people I think using those older versions. This is still something that we have to account for.

Rémi Parmentier: Now, it’s not really that much a problem because between Outlook 2007 and Outlook 2019, unfortunately there weren’t that much of progress made because it’s still Word as a rendering engine. I think this is maybe the worst case we have to support mainly because, yes, we are not getting rid of those versions of Outlook anytime soon, I think.

Vitaly: That’s very optimistic, a bright outlook in life. I like that. I respect that. Thank you so much, Rémi, for being with us today and sharing all the wonderful insights.

Rémi Parmentier: Thank you for having me.

Vitaly: Of course. Will you be kind enough to share the slides of your presentation as well?

Rémi Parmentier: Yes, absolutely.

Vitaly: If you have any other resources that come to your mind, please send them over to us and we’ll publish them, too.

Rémi Parmentier: Sure.

Vitaly: All right? That’s been very exciting. It wasn’t actually as dirty as I thought it would be. Just humble in a way, even. I didn’t see anything that would screech and make me feel uncomfortable at night when I want to sleep. Thank you so much for that, Rémi.

Rémi Parmentier: Thank you.

Vitaly: On that note, Scott, any other updates we should keep in mind or anything we need to mention?

Scott: I was going to ask you, Vitaly. Tomorrow, we have another Smashing TV.

Vitaly: Yes. Friends, we’re trying something else and something new every time. Apparently, well, finally, today we got … I hope we received, because I didn’t get the confirmation yet, but we’re supposed to receive the first copies of the Smashing Print or our new printed magazine dedicated to topics that are often not covered well enough on the web, or maybe that just got lost in the myriad of workflows.

Vitaly: The first issue is dedicated to ethics and privacy. As a dedication to that, we’re going to have a live session, a live stream on Smashing TV tomorrow with five panelists, all contributors to this first issue of Smashing Print. It’s going to be broadcasted on YouTube. If you go on Smashing.TV, you’ll find the links, but we also will be publishing an article tomorrow featuring the links and everything.

Vitaly: The printed magazine, that by the way, Smashers, the ones with $9 plan are getting it for free, and the members with $5 plan are getting the ebook and the heavy discount on the ebook as well. Rémi is getting a printed magazine as well just because he’s so awesome.

Rémi Parmentier: Thank you.

Scott: Thanks, Rémi.

Vitaly: Beyond that, we also have a few more things coming up, I think.

Scott: On the 13th, Mr. Paul Boag, who has been a very prominent mentor in the Smashing community, many Smashing Conferences, many webinars, August 13th, Paul Boag is doing the customer journey mapping where UX and marketing meet.

Vitaly: Then we have Cassie Evans on August 20th exploring the interactive web animation with SVG. This is going to be fun as well. If you actually ever wanted to do a bit more or try to figure out a better workflow for SVG animation, that’s definitely a session not to miss, so looking forward to that.

Vitaly: All right, I think we’re good here. Any more announcements, major announcements, Scott, that we need to share with the world around us?

Scott: You’re making me feel like I’m forgetting something, but … SmashingConf Freiburg?

Vitaly: Yes, we do have a SmashingConf Freiburg, where Rémi is going to speak as well, but we also have the videos of Toronto conference which will be released today, or maybe tomorrow. Maybe they already released. See how well-prepared I am. Watch out for that and you’ll get them, you’ll find them also in your dashboard, so keep that in mind. All right. I think we’re good!

Scott: Okay. Thank you everybody for attending. Thank you-

Vitaly: Thanks, everyone, for attending.

Rémi Parmentier: Bye! Thank you and bye.

Vitaly: Thank you and see you next time. Thank you, Rémi. Bye-bye.

Rémi Parmentier: Thanks. Bye.

Vitaly: See you next time.

SmashingConf Freiburg Presentation “Think Like An Email Geek”

At the end of the Webinar, Vitaly mentions that Remi will be speaking at Freiburg. You don’t have to wait for that as we also have that video to share with you, along with the slides and resources.

We hope you enjoyed this look into HTML email. If you would like to enjoy more of this kind of content, plus the chance to interact with the presenters and other members while helping to support the creation of independent content for web designers and developers join us here.

(ra, vf, il)
Categories: Design

Better Design With Deep Thinking

Wed, 11/13/2019 - 03:00
Better Design With Deep Thinking Better Design With Deep Thinking Eric Olive 2019-11-13T11:00:00+00:00 2019-11-13T13:07:20+00:00 <p>Interruptions, administrative tasks, and too many meetings are among the common complaints voiced by today’s professionals. When was the last time someone complained about a canceled meeting? In other words, everyone understands what hinders productivity, right?</p> <p>Not so fast, says computer scientist Cal Newport. While we all realize that interruptions and fragmented time are troublesome, we fail to recognize:</p> <ul> <li>The frequency of interruptions: We convince ourselves that we are focusing on one task at a time, such as a complex interaction design problem. Yet, every ten minutes or so, we check email or answer a text. Yes, we’re performing one task at a time, but the <strong>duration</strong> of that task is brief.</li> <li>The cost of these interruptions: As Newport explains on a recent episode of <a href="">Hidden Brain</a>: “Even those very brief checks that switch your context even briefly can have this massive negative impact on your cognitive performance. It&rsquo;s the <strong>switch itself that hurts</strong>, not how long you actually switch.” (Emphasis mine)</li> </ul> <p>This task switching was the focus of <a href="">a study</a> by business professor Sophie Leroy. She gave participants a cognitively demanding activity, such as solving a puzzle, and then briefly interrupted them before they completed it. When they returned to the original task, their performance dropped. As Leroy explains, these “results indicate it is difficult for people to transition their attention away from an unfinished task and their subsequent task performance suffers.”</p> <p>Leroy calls this carryover from one activity to another “attention residue,” meaning that people are still thinking about the previous task even as they turn to the new one.</p> <p>The most effective way to avoid attention residue is to structure your work in a way that reduces interruptions. Such structure requires understanding the difference between deep and shallow work.</p> <div data-component="FeaturePanel" data-audience="non-subscriber" data-remove="true" class="feature-panel-container hidden"></div> <h3 id="deep-work-shallow-work-and-why-they-matter">Deep Work, Shallow Work, And Why They Matter</h3> <p>“Deep work is the ability to focus without distraction on a cognitively demanding task,” writes Newport in his book <a href=";qid=1570223166&amp;sr=8-1">Deep Work</a>. This work allows us to absorb, understand, and act on complicated information. Examples including coding, complex project plans, user research, and sophisticated design work.</p> <p>Shallow work refers to tasks that do not require extensive thought and focus such as filling out expense reports and answering emails, texts, and Slack messages.</p> <p>Shallow tasks are necessary. The question is how much time to devote to shallow and deep work and how to structure work in a way that facilitates reflection and concentration.</p> <figure class=" break-out article__image "> <a href=""> <img srcset=",q_auto/w_400/ 400w,,q_auto/w_800/ 800w,,q_auto/w_1200/ 1200w,,q_auto/w_1600/ 1600w,,q_auto/w_2000/ 2000w" src=",q_auto/w_400/" sizes="100vw" alt="Left image: Design is deep work. Right image: Filling out a checklist is shallow work." /> </a> <figcaption class="op-vertical-bottom"> Left: Design is deep work. Right: Filling out a checklist is shallow work. (Image credits: <a href='ttps://'>FirmBee</a> &#124; <a href=''>raw pixel</a>) (<a href=''>Large preview</a>) </figcaption> </figure> <h3 id="the-solution-five-practical-tips-for-pursuing-deep-work">The Solution: Five Practical Tips For Pursuing Deep Work</h3> <h4 id="tip-1-jump-into-design-work">Tip 1: Jump Into Design Work</h4> <p>Avoid the temptation to text or check email first thing. Put your phone on do not disturb. Get out your sketch pad or open your design tool and challenge yourself to solve one gnarly design problem by 10:00 am.</p> <p>While this tip sounds like common sense, it’s not quite so straightforward because we are conditioned to respond to signals around us: “External triggers are cues from our environment that tell us what to do next. These are the dings and pings that prompt us to check our email, answer a text, or look at a news alert,” explains habit expert Nir Eyal in a<a href=""> post about distraction</a>.</p> <p>Eyal continues: “Competition for our attention can come from a person as well, such as an interruption from a coworker when we are in the middle of doing focused work.”</p> <p>Computer scientist Cal Newport expands on this point by explaining the biology behind the itch to respond. When we don’t reply promptly to a text or email, we feel like we are ignoring someone from our tribe. Emotionally, it’s the modern-day equivalent of ignoring someone who is tapping on our shoulder as we sit around the fire. In short, it’s difficult to ignore messages and requests from co-workers.</p> <p>Difficult but not impossible. Extend jumping into design work by blocking out untouchable time on your calendar. What about emergencies? “The short answer is that there really never are any,” writes podcaster and New York Times bestselling author, Neil Pasricha in<a href=";utm_source=twitter&amp;utm_medium=social"> Why You Need an Untouchable Day Every Week</a>. These untouchable days involve deep, creative work.</p> <p>While most professionals cannot set aside an entire day each week, they can mark two-hour blocks on their calendar a few times each week. Colleagues simply see “busy” when viewing your calendar. While not foolproof, this quiet signal shows that you know how to manage your time in order to engage in the deep work that your job requires.</p> <div class="sponsors__lead-place"></div> <h4 id="tip-2-kickstart-your-brain-with-useful-questions">Tip 2: Kickstart Your Brain With Useful Questions</h4> <p>By definition, deep work takes time and considerable brain resources. Sometimes we need a cognitive boost before tackling the problem head-on. When this is the case, ease into deep work by composing a list of questions to stimulate reflection. For example:</p> <ul> <li>What is the organization trying to accomplish?</li> <li>How does this site, product, or app align with that goal?</li> <li>If revising an existing design: What would I do differently if I could recreate the design from scratch?</li> <li>What would I do now if there were no legacy system constraints?</li> </ul> <p>Note that these questions involve design but also encourage reflection beyond the immediate design challenge. The latter is important because the longer you work on a product or project, the easier it is to develop design blinders.</p> <figure class=" "> <a href=""> <img srcset=",q_auto/w_400/ 400w,,q_auto/w_800/ 800w,,q_auto/w_1200/ 1200w,,q_auto/w_1600/ 1600w,,q_auto/w_2000/ 2000w" src=",q_auto/w_400/" sizes="100vw" alt="" /> </a> <figcaption class="op-vertical-bottom"> Kickstart your brain (Image credit: <a href=''>geralt</a>) (<a href=''>Large preview</a>) </figcaption> </figure> <p>Easing into deep work or jumping in with both feet are often useful as long as it’s possible to avoid those nettlesome distractions. Even so, everyone gets stuck and needs time to regroup and let the mind wander.</p> <h4 id="tip-3-schedule-unstructured-thinking-time">Tip 3: Schedule Unstructured Thinking Time</h4> <p>Just as designers and other professionals need time to think through complex problems, they also need time to let the mind wander. The reason is the science behind “shower moments,” when ideas seem to arrive out of the blue.</p> <p>In fact, the brain needs time for incubation, the <a href="">psychological term for the unconscious recombination of thought</a> processes after they are stimulated by conscious mental effort such as working on a specific design problem. In other words, when you set aside a strenuous mental task and do something less demanding, the brain is able to process and organize your thoughts to form new ideas.</p> <p>Effective leaders value unstructured thinking time as outlined in <a href="">How to Regain the Art of Lost Reflection</a>. Jeff Weiner, CEO at LinkedIn, blocks at least 90 minutes for reflection and describes these buffers as “the single most important productivity tool” he uses. Susan Hakkarainen, Chairman and co-CEO of Lutron Electronics, uses 40-minute walks to reflect explaining that “Thinking is the one thing you can’t outsource as a leader. Holding this time sacred in my schedule despite the deluge of calls, meetings, and emails is essential.”</p> <p>In short, designers should take their cues from these business leaders. Give your brain a break.</p> <div class="sponsors__lead-place"></div> <h4 id="tip-4-vote-it-off-the-island">Tip 4: Vote It Off The Island</h4> <p>This tip comes from the Harvard Business Review article <a href="">Stop Doing Low-Value Work</a> by Priscilla Claman. She cites the example of a controller who was producing monthly reports that nobody read. He sent a list to his colleagues asking them to identify the three or four most important reports. He simply stopped writing the reports that no one was reading.</p> <p>Another approach is to request permission to not do something such as asking customers if they really want their receipts. The point, writes Claman, is to stop doing something that is not important but to ask first to avoid getting in trouble. <strong>It’s vital that we stop ourselves from doing unimportant work</strong>.</p> <p>Designers can identify possibly unimportant work by asking if:</p> <ul> <li>Every wireframe must include detailed annotations;</li> <li>Every design deliverable must include a detailed design document;</li> <li>It’s really necessary to produce many variations of a design when studies <a href=";keywords=barry+schwartz+the+paradox+of+choice&amp;qid=1570220933&amp;sprefix=barry+schwartz%2Caps%2C194&amp;sr=8-1">about choice</a> and <a href="">decision making</a> show that too many options make it harder to reach a decision.</li> </ul> <p>No one wants to feel as if their work is sitting on a virtual shelf. By asking clients and stakeholders what matters to them, you’ll cater to their needs and save time by discarding unnecessary tasks.</p> <p>The next step is to assess the remaining important work to determine how much time you can, and should, devote to deep thinking.</p> <h4 id="tip-5-distinguish-deep-and-shallow-work">Tip 5: Distinguish Deep And Shallow Work</h4> <p>Follow the steps below to make this assessment concrete, something you can point to and share with your boss.</p> <ol> <li>Identify the activities that you consider deep work such as planning a usability test, drawing wireframes, or mocking up a prototype.</li> <li>Identify shallow work activities like answering emails, attending administrative meetings or meetings tangentially related to your core responsibilities.</li> <li>Estimate the amount of time you spend on deep and shallow work each week.</li> <li>Meet with your boss for thirty minutes and ask her what she thinks the ratio of deep to shallow work should be. Ask for a specific number. If you disagree, politely ask if you may experiment with a different ratio for one month.</li> <li>Then, stick to the agreed-upon number for one month. Document any changes to your productivity, anything that contributes to a better product or service. After one month, report these findings to your boss.</li> </ol> <p>This approach offers two advantages:</p> <ul> <li>It’s usually wise to solicit the boss’s support.</li> <li>A single proposal about deep work will not change an entire organization. Involving management, however, can serve as a catalyst for broader change just as the <a href=";linkCode=df0&amp;hvadid=266094129756&amp;hvpos=1o2&amp;hvnetw=g&amp;hvrand=4697014055740886414&amp;hvpone=&amp;hvptwo=&amp;hvqmt=&amp;hvdev=c&amp;hvdvcmdl=&amp;hvlocint=&amp;hvlocphy=9032434&amp;hvtargid=pla-436091533585&amp;psc=1">Google Ventures Design Sprint</a> influenced the design process at Google and beyond.</li> </ul> <h3 id="why-deep-work-makes-everything-better">Why Deep Work Makes Everything Better</h3> <p>Deep work allows designers and developers to thrive by leveraging their skills to solve complex problems and create better products and designs. Better products are likely to boost the bottom line while thriving and highly satisfied employees are more likely to stay (reducing turnover) and put their best selves forward.</p> <p>Perhaps the best news for employers is that deep work does not require adding staff. The solution, explains computer scientist Cal Newport, is to <strong>re-configure work and communication</strong>. In other words, it’s not more people; it’s the same people managing work differently.</p> <p>For example, agencies often answer to clients and need to be available at a moment’s notice. Rather than require every employee to be tethered to a phone or laptop, Newport suggests assigning a different employee each day to a dedicated email or a special “bat phone.” This shows the client their importance to the agency while also allowing designers to concentrate on designing, building, and solving problems.</p> <h3 id="conclusion">Conclusion</h3> <p>Deep work is the ability to focus on challenging tasks like design and coding. Frequent interruptions make deep work nearly impossible and impose a high financial cost. In this piece, we’ve described five tips for maximizing the time you devote to deep work.</p> <ol> <li><strong>Jump into design work.</strong><br /> Draw fresh wireframes or work on a new design problem before checking emails and Slack messages. Block two-hour chunks on your calendar to allow time for deep thinking.</li> <li><strong>Kickstart your brain with useful questions.</strong><br /> Take a few minutes to ask what you are trying to accomplish and how it aligns with the company’s keep performance indicators (KPIs). Alignment with KPIs is especially important for user experience designers who are frequently asked to justify their budget</li> <li><strong>Schedule unstructured thinking time.</strong><br /> Take a walk, stare out the window, or whatever allows your mind to wander. This “downtime” allows the brain to form new connections.</li> <li><strong>Vote it off the island.</strong><br /> Are you writing reports that no one reads? Are you scheduling meetings that your co-workers find less than useful? Ask your colleagues if it’s okay to stop. They might respond with a gleeful “yes!”</li> <li><strong>Distinguish deep and shallow work.</strong><br /> Then, meet with your boss to arrive at the right balance between these two types of work.</li> </ol> <h4><span class="rh">Further Reading</span> on SmashingMag:</h4> <ul> <li><a title="Read 'How People Make Decisions'" href="" rel="bookmark">How People Make Decisions</a></li> <li><a title="Read 'Maximizing The Design Sprint'" href="" rel="bookmark">Maximizing The Design Sprint</a></li> <li><a title="Read 'Creating Online Environments That Work Well For Older Users'" href="" rel="bookmark">Creating Online Environments That Work Well For Older Users</a></li> <li><a title="Read 'User Experience Psychology And Performance: SmashingConf Videos'" href="" rel="bookmark">SmashingConf Videos: User Experience Psychology And Performance</a></li> </ul> <div class="signature"> <img src="" alt="Smashing Editorial"> <span>(ah, il)</span> </div>
Categories: Design

Adapting Agile For Part-Time Teams

Tue, 11/12/2019 - 04:00
Adapting Agile For Part-Time Teams Adapting Agile For Part-Time Teams Philip Kiely 2019-11-12T12:00:00+00:00 2019-11-13T07:06:34+00:00 <p>The formal notion of the Agile software development method is about as old as I am (the Agile Manifesto was published in February 2001). I point this out not to <a href="">make you feel old</a>, but instead to demonstrate that Agile has had a long time to infiltrate software development. While the methodology advocates for &ldquo;co-located, dedicated teams,&rdquo; in its ubiquity Agile is frequently applied to teams partially or fully composed of part-time workers. While there are lessons to be taken from the practice, Agile must be adapted to support, rather than hinder, part-time teams.</p> <p>In this article, we’ll consider applying Agile to a team of 5-10 people each working 20 hours per week on a project. We’ll further consider the frequent intersection of remote work with part-time teams and discuss situations where contributors work as few as 5 hours per week on a project. We’ll also hear from professors Armando Fox at the University of California, Berkeley and Barbara Johnson at Grinnell College with their thoughts on part-time Agile teams.</p> <h3 id="why-does-part-time-work-happen">Why Does Part-Time Work Happen?</h3> <p>While the &ldquo;5 developers for 20 hours&rdquo; example may seem contrived, many situations lead to the scenario. You may have:</p> <ul> <li>Developers assigned to multiple clients, projects, or teams within a single company,</li> <li>A team with contractors or co-op interns,</li> <li>Volunteers working on an open-source or community project, or</li> <li>An after-hours team working on a startup or product.</li> </ul> <p>While we will examine the many challenges involved in managing teams under these constraints, usually the alternative to working part-time with someone isn’t their full-time efforts, the alternative is not being able to work with them at all. While part-time workers and teams often require extensive compromises, with clear and effective management they can still be a huge net positive to a team and business.</p> <div data-component="FeaturePanel" data-audience="non-subscriber" data-remove="true" class="feature-panel-container hidden"></div> <h3 id="tenets-of-agile">Tenets Of Agile</h3> <p>Given its prevalence in the software development industry, everyone understands Agile slightly differently. To get through adapting the framework together, we need a shared vocabulary to define &ldquo;regular&rdquo; Agile, you know, the kind that advocates for &ldquo;dedicated, co-located teams.&rdquo; Agile implements practices, rituals, and roles to promote effective work.</p> <p>Agile, as implemented, involves certain practices:</p> <ul> <li>&ldquo;Sprints&rdquo; are discrete units of time, often 2 weeks, that determine the cycle of work for Agile teams.</li> <li>&ldquo;Stories&rdquo; or &ldquo;user stories&rdquo; are well-scoped units of work that a single team member can complete in some fraction of the sprint.</li> <li>Often, teams organize their stories on &ldquo;kanban boards&rdquo; or similar methods of tracking story state: to do, in progress, in review, and done in a given sprint.</li> </ul> <p>Agile revolves around four rituals:</p> <ol> <li><strong>Sprint Planning</strong><br /> This is a meeting that opens each sprint with writing, estimating, prioritizing, and assigning stories that the team intends to complete for the sprint.</li> <li><strong>Daily Stand-Up</strong><br /> A chance for teams to meet every day to discuss the previous day’s progress, discuss the day’s work, and raise any roadblocks. Ideally, the meeting is very short (5-15 minutes) and is near the start of the workday to minimize the interruption of dedicated work time.</li> <li><strong>Sprint Review</strong><br /> This is part of a meeting which ends each sprint with a review of work accomplished, new backlog items, missed estimates, and other quantifiers of team progress.</li> <li><strong>Sprint Retrospective</strong><br /> A discrete meeting or block of time for discussing what went well and what to improve about how the team operates in qualitative terms.</li> </ol> <p>Agile teams usually have distinct, cross-functional roles. Common roles include:</p> <ul> <li>The &ldquo;project manager/team lead&rdquo; manages the team, assigns work, reports to management, assists team members, and performs other managerial duties.</li> <li>The &ldquo;scrum master&rdquo; is responsible for leading Agile rituals.</li> <li>A &ldquo;product owner/product manager&rdquo; represents the client or end-user to the team. They have an active hand in writing stories, reviewing product functionality, and communicating progress to clients and expectations to the team.</li> <li>An &ldquo;individual contributor&rdquo; is any member of the team whose main responsibility is building the product. Developers, designers, QA specialists and writers are all examples of individual contributors.</li> </ul> <p>While these definitions are important for our shared understanding, the major theme of this article is that achieving your team’s goals is more important than implementing &ldquo;proper&rdquo; Agile. If this doesn’t exactly match your setup, common elements should help apply upcoming recommendations to your experience.</p> <figure class=" "> <a href=""> <img srcset=",q_auto/w_400/ 400w,,q_auto/w_800/ 800w,,q_auto/w_1200/ 1200w,,q_auto/w_1600/ 1600w,,q_auto/w_2000/ 2000w" src=",q_auto/w_400/" sizes="70vw" alt="&#39;Scrum Board&#39; by İrfan Simsar on Unsplash" /> </a> <figcaption class="op-vertical-bottom"> (Image credit: ‘İrfan Simsar’ on <a href=''>Unsplash</a>) (<a href=''>Large preview</a>) </figcaption> </figure> <h3 id="constraints-of-part-time-work">Constraints Of Part-Time Work</h3> <p>Immediately, we see how the constraints of part-time work cut into standard Agile. First off, in a given two-week sprint, each employee may spend 2 hours in sprint planning, 10 times 15 minutes in stand-up, 1 hour in sprint review, and 30 minutes in sprint retrospective, for a total of 6 hours in Agile meetings. For a full-time employee, that’s only 7.5% of their 80-hour fortnight, for a half-time employee it doubles to 15%. Add in other meetings and account for context switching and suddenly your individual contributors have very little time left each week to individually contribute.</p> <p>Thus, part-time work exacerbates the need for good capacity estimation and up-front planning while reducing the time available for it. Fortunately, Agile’s notion of story points applies well. Story points estimate effort rather than time and thus stay constantly effective between full-time and part-time workers, though of course part-time workers will take longer to achieve the same amount of story points, which you can account for by measuring the team’s velocity.</p> <p>Even if your development team is part-time, your clients may not be. Customer support, emergency bug fixes, outage repairs, and even regular communication can be more difficult with part-time work adding additional overhead.</p> <figure class=" "> <a href=""> <img srcset=",q_auto/w_400/ 400w,,q_auto/w_800/ 800w,,q_auto/w_1200/ 1200w,,q_auto/w_1600/ 1600w,,q_auto/w_2000/ 2000w" src=",q_auto/w_400/" sizes="100vw" alt="&#39;Man in a watch typing&#39; by Brad Neathery on Unsplash" /> </a> <figcaption class="op-vertical-bottom"> (Image credit: ‘Brad Neathery’ on <a href=''>Unsplash</a>) (<a href=''>Large preview</a>) </figcaption> </figure> <div class="sponsors__lead-place"></div> <h3 id="frequently-intersecting-constraints">Frequently Intersecting Constraints</h3> <p>While not all part-time teams will experience these additional challenges, in my experience part-time work often overlaps with remote work, different time zones and availabilities, and classification of workers as temporary, contractors, or interns instead of employees. This is not an article about any of these things, but they bear mentioning.</p> <p>Part-time work adds significant overhead to the already difficult task of finding a regular time when everyone is available to meet. If some team members work in the mornings and others in the evenings or are located across the world from each other, scheduling quickly becomes impossible. GitLab has published <a href="">extensive documentation on remote communication</a> that might be helpful.</p> <p>Working with contractors, student interns, temporary hires, or other non-permanent teams or team members brings its own advantages and challenges. That said, however, someone got to the table, the Agile framework treats them as an equal member of the team and stakeholder in the project.</p> <figure class=" "> <a href=""> <img srcset=",q_auto/w_400/ 400w,,q_auto/w_800/ 800w,,q_auto/w_1200/ 1200w,,q_auto/w_1600/ 1600w,,q_auto/w_2000/ 2000w" src=",q_auto/w_400/" sizes="100vw" alt="&#39;Untitled&#39; (Meeting) by You X Ventures on Unsplash." /> </a> <figcaption class="op-vertical-bottom"> (Image credit: ‘You X Ventures’ on <a href=''>Unsplash</a>) (<a href=''>Large preview</a>) </figcaption> </figure> <h3 id="redefining-rituals-for-part-time-teams">Redefining Rituals For Part-Time Teams</h3> <p>Now that we’ve framed the challenges that part-time work creates, let’s focus on solutions. While I’ve seen a number of successful modifications to Agile rituals for part-time teams, I reached out to Professor Armando Fox, co-author of <em>Engineering Software as a Service: An Agile Approach Using Cloud Computing</em> with David Patterson. In an email interview, he emphasized two key goals of agile rituals to retain:</p> <blockquote>“The reason Agile is a good fit [for part-time teams] is the idea of using user stories as the unit of work. The key to doing this successfully is up-front planning and continuous check-ins.”<br /><br />&mdash; Armando Fox</blockquote> <p>Sprint planning condenses up-front planning to a single high-value meeting. For part-time teams, the product owner, scrum master, and team lead (who may be only one or two people, more on that later) should do as much pre-meeting work as possible to define well-scoped tickets for the individual contributors to estimate and take. Fox said &ldquo;if stories are tightly-circumscribed, branches are short-lived, stories require modest amounts of code that can be delivered with good test coverage, and code quality is maintained through continuous code review (pull requests) as well as the use of code quality measurement tools, the team can successfully divide-and-conquer even if they’re not always working at the same time.&rdquo; That’s definitely a lot of &ldquo;if&rdquo; statements, working in this manner will take dedicated effort from the entire team, but should result in a quality product.</p> <p>The other half of the equation is continuous check-ins. Agile’s daily stand-ups work great for co-located full-time teams, if everyone’s in the office by 9 or 10 AM the meeting happens more or less naturally. It’s tempting to replace this with an asynchronous check, like status-report emails, but Fox advocates that teams stick to the ritual. &ldquo;The team needs to check-in frequently &mdash; we recommend daily 5-minute stand-ups &mdash; so that any red flags can be spotted early. Even part-time teams can find 5 minutes a day that the whole team is available. Email isn’t good for this; an interactive meeting, where people can also mention blocking items and others can immediately speak up with suggestions, is the best format,&rdquo; he wrote.</p> <p>For a part-time team, it may also be tempting to do away with regular meetings entirely and rely solely on the start and end of sprint check-ins. Fox warns that &ldquo;every team [that he has] coached at Berkeley has said that they quickly realized that once-a-week team meetings were nowhere near enough to keep everyone on the same page.&rdquo;</p> <p>Sprint reviews and retrospectives are important components of Agile. If teams do not regularly evaluate their working practices and performance, bad interactions will continue unchecked and discontent will grow. However, the velocity measurement and end-of-sprint re-assignment tasks can be handled by the scrum master outside of meeting times, and the team leader can use one-on-one meetings and their perception of team mood in stand-ups and sprint planning to reduce the need for sprint review and retrospective.</p> <p>If you absolutely need to cut back on the number and duration of Agile meetings, cut review and retrospective first. That said, it is important to celebrate the team’s progress each sprint and give people space to air grievances. A decent compromise can be to extend the last stand-up of each sprint to accomplish this communication within the team.</p> <div class="sponsors__lead-place"></div> <h3 id="defining-roles-on-a-part-time-agile-team">Defining Roles On A Part-Time Agile Team</h3> <p>This section depends entirely on the composition of the team. However, there are a few useful heuristics for assigning roles. Responsibilities assigned should minimize communication overhead (which scales worse-than-linearly with team size), fit individual contributors&rsquo; abilities, and account for team members&rsquo; schedules and availability.</p> <p>For this section, I turned to Professor Barbara Johnson, who teaches a team software development course that I am currently enrolled in at Grinnell College. She wrote:</p> <blockquote>“I have sometimes seen teams come to rely upon what might be called a 'chief organizer' who combines the roles of not only a scrum master (who organizes the team) but also the product owner (who coordinates and documents the client’s needs and feedback). This lessens the cognitive overhead of the rest of the team, who then can focus more on moving the project’s code and testing suite forward with each iteration.”</blockquote> <p>This matches my experience with part-time teams.</p> <p>If possible, condense the managerial positions (team lead, product manager, scrum master) into a single role and assign that role to the &ldquo;fullest-time&rdquo; team member. If you have a team of 10 where only 1 person is full-time or otherwise has greater availability, that person should have as many organizational and communication responsibilities as feasible. Part-time teams require just as much communication as full-time teams and an even greater logistical effort, so concentrating that work in one person massively reduces communication overhead.</p> <p>However, frequently this isn’t possible, either because no one has extra availability or because those people are better suited to individual contributor roles. In that case, I still advocate for condensing managerial responsibilities as much as possible but breaking the product owner back out into its own role. In this case, it’s important to be realistic when estimating how much further work these people will be able to do on user stories considering their other work for the team and client.</p> <p>Most of the members of the part-time team will be individual contributors. There are two competing philosophies for individual contributors: generalist teams and teams of specialists. Imagine that your team is developing a web application. A generalist team would be composed of entirely full-stack developers. These developers would never be blocked on others&rsquo; work as, in theory, they are equally comfortable on anything from design to deployment. Alternately, if a designer, front-end engineer, back-end engineer, and site reliability engineer comprise a team, they will be fast and effective at their own work because they only spend their time on the thing that they’re best at.</p> <p>As a team organizer, you may find yourself with a team of generalists, a team of specialists, or a mix. Putting together a part-time team of solid performers is hard enough without restricting yourself to one type of individual contributor, so, fortunately, both types bring something useful to the table. If you can recognize which of your individual contributors are generalists and which are specialists, you can assign tasks more effectively to maximize the impact of their limited work time.</p> <p>Finally, on teams where people are working ten or fewer hours per week, it is tempting to throw out roles entirely and just say &ldquo;do what you can.&rdquo; Per our theme, these super-part-time teams need even more structured communication but have even less time for it. If everyone has such limited, scattered availability that you cannot justify assigning roles at all, it’s probably worth re-examining the structure, goals, and feasibility of the project.</p> <figure class=" "> <a href=""> <img srcset=",q_auto/w_400/ 400w,,q_auto/w_800/ 800w,,q_auto/w_1200/ 1200w,,q_auto/w_1600/ 1600w,,q_auto/w_2000/ 2000w" src=",q_auto/w_400/" sizes="100vw" alt="&#39;At the bustling Times Square&#39; by Saulo Mohana on Unsplash" /> </a> <figcaption class="op-vertical-bottom"> (Image credit: ‘Saulo Mohana’ on <a href=''>Unsplash</a>) (<a href=''>Large preview</a>) </figcaption> </figure> <h3 id="client-communication">Client Communication</h3> <p>Software development is slow, complex work, and part-time teams only magnify that truth. Agile includes the client in the process by writing user stories, rapid prototyping, a quick release schedule, and consistent communication.</p> <p>As a part-time team, communicate reasonable expectations to the client. For a half-time team, remember that development time is cut by more than half, build an extra buffer into doubled estimates. As development time is limited, it is critical to solicit complete, accurate specifications when meeting with the client or end-users to avoid wasting your efforts.</p> <p>Don’t let part-time work make you fall behind on client communication. Even if there is very little progress to report, soliciting regular feedback and posting updates at a reasonable cadence should increase the client’s patience with the slow development pace.</p> <h3 id="conclusion-goals-methods">Conclusion: Goals &gt; Methods</h3> <p>You can get a lot done in a part-time schedule. Outside of coding, 10-20 hours per week is enough time to train for a first marathon. With a strong team and good working practices, it is enough time to bring a great product to the market. Using Agile to encourage up-front planning and continuous check-ins with user stories, regular stand-ups, and well-defined roles will allow even part-time teams to overcome communication barriers and work effectively towards a shared goal.</p> <h4><span class="rh">Further Reading</span> on SmashingMag:</h4> <ul> <li><a title="Read 'Bringing A Healthy Code Review Mindset To Your Team'" href="" rel="bookmark">Bringing A Healthy Code Review Mindset To Your Team</a></li> <li><a title="Read 'Building Diverse Design Teams To Drive Innovation'" href="" rel="bookmark">Building Diverse Design Teams To Drive Innovation</a></li> <li><a title="Read 'The Case For Brand Systems: Aligning Teams Around A Common Story'" href="" rel="bookmark">The Case For Brand Systems: Aligning Teams Around A Common Story</a></li> <li><a title="Read 'Creating Authentic Human Connections Within A Remote Team'" href="" rel="bookmark">Creating Authentic Human Connections Within A Remote Team</a></li> </ul> <div class="signature"> <img src="" alt="Smashing Editorial"> <span>(dm, yk, il)</span> </div>
Categories: Design

SmashingConf New York 2019: Videos And Photos

Tue, 11/12/2019 - 02:00
SmashingConf New York 2019: Videos And Photos SmashingConf New York 2019: Videos And Photos Rachel Andrew 2019-11-12T10:00:00+00:00 2019-11-13T07:06:34+00:00 <p>We love running our event in New York, and given that it sold out a long way in advance we think that you do too. If you didn&rsquo;t manage to get a ticket, this post should give you a feel for what happened. We also have the video of the presentations to share with you.</p> <p>Enjoy this roundup, and if you want to be there in person for one of our events next year, tickets are on sale right now!</p> <figure class=" break-out article__image "> <a href=""> <img srcset=",q_auto/w_400/ 400w,,q_auto/w_800/ 800w,,q_auto/w_1200/ 1200w,,q_auto/w_1600/ 1600w,,q_auto/w_2000/ 2000w" src=",q_auto/w_400/" sizes="100vw" alt="A set of mock show posters feature the Smashing cat" /> </a> <figcaption class="op-vertical-bottom"> Topple the Cat greeted attendees by way of our Broadway posters (Photo credit: <a href=''>Drew McLellan</a>) </figcaption> </figure> <ul> <li><a href="#the-presentations">The Presentations</a></li> <ul> <li><a href="#day-1">Day 1</a></li> <li><a href="#day-2">Day 2</a></li> </ul> <li><a href="#workshops">Workshops</a></li> <li><a href="#side-activities">Side Activities</a></li> <ul> <li><a href="#morning-run">Morning Run</a></li> <li><a href="#evening-events">Evening Events</a></li> </ul> </ul> <h3 id="the-presentations">The Presentations</h3> <p>The main focus of the conference is the speakers and the presentations they bring. As with all of our 2019 events, some speakers opted to present without slides.</p> <figure class=" break-out article__image "> <a href=""> <img srcset=",q_auto/w_400/ 400w,,q_auto/w_800/ 800w,,q_auto/w_1200/ 1200w,,q_auto/w_1600/ 1600w,,q_auto/w_2000/ 2000w" src=",q_auto/w_400/" sizes="100vw" alt="One person in the middle of the stage, two behind a desk" /> </a> <figcaption class="op-vertical-bottom"> Brad Frost, Dan Mall, and Ian Frost co-presenting (Photo credit: <a href=''>Drew McLellan</a>) </figcaption> </figure> <p>In the tables below, I’ve linked to slides for those talks which had them, plus the video of each presentation. Enjoy two days worth of learning from the comfort of your own couch!</p> <h4 id="day-1">Day One</h4> <p>The <a href="">Day One Collaborative Doc</a> created by attendees is full of takeaways from the first day of the conference.</p> <table class="tablesaw break-out" data-tablesaw-mode="stack" data-tablesaw-minimap> <thead> <tr> <th data-tablesaw-priority="persist">Speaker Name</th> <th>Talk Title</th> <th>Video &amp; Slides</th> </tr> </thead> <tbody> <tr> <td>Dan Mall and Brad Frost</td> <td>Designer vs. Developer</td> <td><a href="">Video</a>, <a href="">Slides</a></td> </tr> <tr> <td>Marcy Sutton</td> <td>Garbage Pail Components</td> <td><a href="">Video</a>, <a href="">Slides</a> </td> </tr> <tr> <td>Trine Falbe</td> <td>Designing For Kids Is Not A Game</td> <td><a href="">Video</a>, <a href="">Slides</a></td> </tr> <tr> <td>Denys Mishunov</td> <td>I Built A Frankenstein Monster: 3 Stories Of Migration</td> <td><a href="">Video</a>, <a href="">Slides</a></td> </tr> <tr> <td>Maggie Wachs</td> <td>Lessons Learned From A Decade Of Building Pattern Libraries</td> <td><a href="">Video</a>, <a href="">Slides</a></td> </tr> <tr> <td>Wes Bos</td> <td>Slam Dunk Your JavaScript Fundamentals</td> <td><a href="">Video</a>, <a href="">Slides</a></td> </tr> </tbody> </table> <h4 id="day-2">Day Two</h4> <p>Check out the <a href="">Day Two Collaborative Doc</a> for more resources and thoughts from our attendees and speakers.</p> <p>Our mystery speaker was dina Amin. The Smashing Team love her <a href="">Instagram</a>!</p> <blockquote class="twitter-tweet"><p lang="en" dir="ltr">Mystery speaker was soooo good! Dina’s talk about the stop motion animation and her videos blew the minds away of the audience! Enjoyed every bit of it <a href=";ref_src=twsrc%5Etfw">#smashingconf</a>
Categories: Design

How To Stop Analysis Paralysis With Design

Mon, 11/11/2019 - 02:30
How To Stop Analysis Paralysis With Design How To Stop Analysis Paralysis With Design Suzanne Scacca 2019-11-11T10:30:00+00:00 2019-11-11T12:05:31+00:00

As a web designer, you do your best to remove friction from the decision-making process. You place only one CTA above the fold. You keep interactive elements to a minimum. You make the menu only as large as it needs to be.

But what happens when the content itself causes analysis paralysis?

There’s an overabundance of choice all around the web, from e-commerce stores with thousands of products to content generation machines pushing out new posts every day. While you can’t do anything to stop the flood of information or items going out to your visitors, you can design your interfaces in a way that makes the decision-making process easier to bear. What’s more, you can help them walk away feeling more confident with their choice, too.

Let’s look at what it is about the psychology of choice that can be detrimental for conversions and what you can do to keep your PWA visitors from succumbing to it.

Why Analysis Paralysis Is Hurting Your Conversion Rate

Paralysis by analysis is what happens when someone finds a situation or decision too overwhelming or difficult. Despite thinking over the circumstances or options, they’re unable to make a clear choice, often leading to no action at all.

It’s the exact opposite of what we want to happen with our visitors and customers. And, yet, we see it all the time.

Take Amazon, with its hundreds of millions of products. Let’s say a shopper is looking for socks for an upcoming snowboarding trip. So, they search for “snowboard socks”:

A search for “snowboard socks” on Amazon yields 728 results. (Source: Amazon) (Large preview)

There are 728 matching results for snowboard socks. While that’s nothing compared to the size of Amazon’s marketplace, it’s still way too many results to sift through on one’s own.

So, the shopper decides to narrow their search down to “knee-high snowboard socks antimicrobial compression”, which hits all of the key features they’re looking for:

A search for “knee high snowboard socks antimicrobial compression” on Amazon yields 8 results. (Source: Amazon) (Large preview)

That takes the list of 728 products down to a more manageable 8. However, there are a number of problems with this.

For starters, Amazon doesn’t actually present only eight options. The first thing it shows is a banner with sponsored results:

Amazon displays sponsored products on a search results page before organic products. (Source: Amazon) (Large preview)

The next two rows do contain organic search results. However, the products either don’t have any reviews or high enough ratings to rave about.

To make matters worse, Amazon adds three more rows of sponsored products to the end of this page:

An Amazon search results page promising 8 results is full of sponsored products. (Source: Amazon) (Large preview)

Essentially, Amazon has tripled the number of products the shopper has to look at now. Not only that, but one could argue that it’s polluted the search process with so many paid products.

It’s just a poor experience all around.

It’s a similar story on mobile. The main difference is that, when the narrow search is applied, only five results remain. That said, Amazon continues to muddle search results by prioritizing sponsored posts. This is what the shopper sees above the fold:

Amazon search results display only sponsored products above the fold on mobile. (Source: Amazon) (Large preview)

Once the shopper scrolls, they’ll see two organic products (with no ratings, much less) before being shown yet another sponsored product:

Amazon fills mobile search results with paid product listings. (Source: Amazon) (Large preview)

What should have been a succinct product search page ends up running on and on with sponsored listings and Amazon recommendations. As you can imagine, this is an even bigger problem for mobile shoppers who don’t have the patience or time to waste.

How To Simplify Decision-making With Design

Psychologist Barry Schwartz gave a TED talk on this exact problem and explained how it doesn’t just lead to abandoned purchases, but to less satisfying purchases.

Essentially, Schwartz argues that too many choices cause consumers to:

  • Have too-high expectations whereby no option ever seems perfect or satisfying.
  • Focus on minute details or features they missed out on by not making a different choice.
  • Regret the option they settled on even if it proved to be the best.
  • Blame themselves for spending too much time analyzing a decision and still making the “wrong” choice.

In other words, an abundance of choice puts your audience in the wrong state of mind. And if your site or PWA can’t afford to process returns or watch visitors walk away at a rate that a company like Amazon can, then you can’t let paralysis analysis become part of the decision-making process to begin with.

Here are some things you can do to make decision-making more bearable, even with too many options available.

Prioritize Your “Big Rock”

There’s a productivity hack called the “Big Rocks” method. Essentially, it says that if you want to get more stuff done, you have to take on your biggest challenge or priority first thing. All of the smaller tasks and requests nagging at you get slotted in once you’ve tackled the most critical ones.

And now I’m suggesting you do something similar with your design.

Basically, what you want to do is this:

  • Look at all of the “stuff” you’re trying to put in front of your visitors.
  • Ask yourself (or your client): “Which one takes top priority right now?”
  • Then, stick it to the top of your home page.

Why do this? Well, for starters, it’s much less overwhelming to show one thing than to throw everything you have at your visitors right away — or to force them to dig around and figure out where to start. Plus, chances are good that there’s something especially pressing you want every visitor to see.

BarkShop shows us one way you might do this:

The home page of the BarkShop website displays a Halloween sale banner. (Source: BarkShop) (Large preview)

Notice how the top of the page isn’t littered with an inventory. Instead, the primary focus is on the Halloween sale.

This is clearly BarkShop’s big rock right now. If they don’t get their Halloween items out the door by October 31, they run the risk of losing money on the seasonal inventory. And while they could leave it up to their visitors to assume there are Halloween toys and treats available, why do that?

It’s hard enough showing up on a site like this and deciding what you’re going to buy for your dog this month. So, let your big rock become their guide.

You can see that it’s not just about the Halloween line either. Just below the banner, BarkShop has prioritized its top-trending toys. This is another trick you can use when designing product inventories and news sites. Display the most popular or top-rated/shared items first. There’s a greater likelihood they’re going to click on something that others have shown interest in than a bunch of random items they have to explore on their own.

Another way you might tackle big rocks in design is to go the way of Apple:

The Apple home page banner advertises only its iPhone 11 Pro. (Source: Apple) (Large preview)

Again, Apple could’ve shown a bunch of its iPhones and iPads here or pointed visitors to different categories of products and accessories to explore. Instead, it’s put its big rock right up front: the iPhone 11 Pro.

Sure, there are probably plenty of Apple customers who come here looking for older models. But what makes more sense?

  • Showing a bunch of similar-looking smartphone graphics that visitors are immediately put into analysis paralysis mode with?
  • Or showing them the latest model that everyone wants?

You can do this with other kinds of websites, too. Blogs, for instance, will use the sticky post feature to show off their “big rocks” to every visitor who stops by. This might be the most popular post of all time or it could be something relevant to something happening at the moment.

Whatever it is, there’s a conscious decision made to stop visitors in their tracks and give them a moment of calm before they have to enter decision-making mode.

Gate Off the Choices

While you want your visitors to know that there’s a plenitude of things available, you don’t need to tell them how much there is. It’s only going to add to the pressure of the decision-making process.

So, whenever you can, gate off the choices.

eHealth Insurance is a website where Americans can purchase health insurance for themselves or their companies. With a wide variety of healthcare providers and dozens of plans available for each, a service like this is necessary for insurance-wielding U.S. citizens.

The eHealth Insurance website gates off its insurance provider options and plans. (Source: eHealth Insurance) (Large preview)

The only decision it asks visitors to make is what kind of insurance they’re looking for. It then asks them to fill out a simple enough form. It’s what eHealth Insurance uses to pare down the options:

The eHealth Insurance form asks qualification questions of visitors to help list the right options. (Source: eHealth Insurance) (Large preview)

Once filled out, eHealth Insurance shows the user a list of providers and plans that are available in their area. This keeps the consumer from having to:

  1. Visit individual health insurance websites to do their own research.
  2. Sift through hundreds of options all at once (some of which they’d probably be ineligible for and others that would just be a bad fit).

Websites like these typically allow you to compare up to three items at once, making the decision-making process even simpler.

Another way to gate off your choices is by asking visitors to start narrowing their choices from the moment they arrive as Sotheby’s International Realty does:

The first thing the Sotheby’s International Realty PWA asks visitors to do is narrow down their search results. (Source: Sotheby’s International Realty) (Large preview)

This way, consumers aren’t distracted by all the great-looking properties or even the attractive prices. They’re still focused on taking action (e.g. finding a rental), but it’s more about taking baby steps towards the desired result which makes it much less intimidating. It’s also going to lead to a more satisfying result in the end as they won’t spend time looking at rentals they can’t afford, that don’t allow cats or that are too far away from their kids’ schools.

Sotheby’s helps visitors narrow their searches by location. (Source: Sotheby’s International Realty) (Large preview)

The next page of the Sotheby’s search process starts to show matching results, but not before letting them know that there are “55 Luxury Homes for Rent in London”. And if that number is just too much to handle, that’s fine. Directly to the right of that note is a filters widget.

Sotheby’s helps visitors narrow down their choices even further with comprehensive filters. (Source: Sotheby’s International Realty) (Large preview)

Sotheby’s filters are great. Not only are all the essentials covered, but it’s even divided up the filters by category.

Let’s recap how smooth this experience is going to be for already-anxious home-buyers or renters:

  • The first thing they see on the Sotheby’s home page is a search bar.
  • If they do the search, the next thing they see is the number of properties in the area.
  • If that number is too intimidating, the filters widget is there to help them narrow the list even more.

By keeping the rentals off of the home page and even away from the top of the fold of the internal page, Sotheby’s can control how calmly visitors go through the decision-making process.

Enable Side-by-side Comparison

Internally, there’s not a lot you can do about choice overload except giving your visitors a really great set of sorting and filtering tools. Even then, once they start to see lists of related products, recommendations on previous purchases and so on, the analysis paralysis is going to creep back in.

One thing you can do to make this less stressful is by including side-by-side comparisons.

It’s similar to laying out pricing plans side-by-side. Rather than make prospective customers review their options one-by-one, stack up the top few choices. Then, align the specifications so it’s as easy as looking across a row to weed something out because it doesn’t fit the budget or the product is too large.

Although Amazon doesn’t handle analysis paralysis flawlessly, I do like what it does with its side-by-side product comparisons:

Amazon shows a table of similar products to customers for easy comparison. (Source: Amazon) (Large preview)

I can’t tell you how many times I’ve struggled to make a decision on Amazon, only to discover one of these comparison tables and immediately been able to make up my mind. It’s just so much easier to see a bunch of lookalike products all at once and to say “This one definitely won’t fit in my kitchen” or “That’s the exact color I’m looking for”.

You can do this with other kinds of websites, too. Verizon Wireless, for example, uses a side-by-side comparison to make choosing between its plans easier.

Verizon Wireless displays the details for its 2GB wireless plan. (Source: Verizon Wireless) (Large preview)

There are scroller dots below this block that indicate to customers that there’s more to be found. All they have to do is scroll to reveal more plan options. And because the scroller breadcrumbs are kept to a reasonable amount, this doesn’t seem like that burdensome of a task.

The next block over, for instance, contains the information for the 4GB plan:

Verizon Wireless displays the details for its 4GB wireless plan. (Source: Verizon Wireless) (Large preview)

Even though the specs can’t be seen see side-by-side, the details are simply broken down and are consistently laid out. So, when someone moves from plan to plan, the same details are in the same place which makes flipping back and forth quite easy.

Another thing I really like about this is the summary provided at the top of each card. The 2GB one tells customers right away that it’s the best plan if you mostly talk and text whereas 4GB is better if you stream a lot of content and surf the web. This way, if all the technical details don’t mean much to customers, the layman’s summary will help them more confidently decide.

While I realize side-by-side comparisons might be something you’d normally try to avoid on mobile screens, these two examples show that it is possible to do so without introducing too much friction to the experience.

Wrapping Up

As I said before, you can’t do anything about scaling back the multitude of options your clients want to present their audiences with. If they want to sell thousands of products to customers that are demanding them, then good for them.

That said, the way you design around these options can have an impact on how well or poorly they’re received. Just remember what Barry Schwartz teaches us about the psychology of choice. If your visitors, users or customers walk away feeling overwhelmed, drained or disappointed with the experience, it’s going to cost you. So, be mindful of how much you present the options to them.

(ra, yk, il)
Categories: Design

What Newspapers Can Teach Us About Web Design

Fri, 11/08/2019 - 03:30
What Newspapers Can Teach Us About Web Design What Newspapers Can Teach Us About Web Design Frederick O'Brien 2019-11-08T11:30:00+00:00 2019-11-08T13:36:06+00:00

It’s easy to get caught up in the latest trends in web design. Web technology is constantly improving, and today developers have a formidable range of features at their disposal. This makes for a forward-thinking, innovative space — as it should — but also one at risk of being unrooted. Every art has its ancient masters. In the case of websites, it’s newspapers.

When you dig into the basic principles of news design, overlaps with the web are frequent and oftentimes indistinguishable. Many web design best practices can be traced directly back to news design. When it comes down to it, websites are made for users to engage with, and hopefully return to. Newspapers have been playing that game for centuries, and winning.

Anyone with even a passing interest in web design stands to benefit from knowing how news design works, and why it works. This piece will examine several tenets of newspaper design and show their connection to best practice online. At the core of that connection is a principle childlike in its simplicity, one newspaper and web designers alike would do well to remember.

Hold The Home Page

Newspapers have been around since the 17th century. They’ve worked hard for their rules, and because their content changes daily the rules have to be abstract. Ninety-five percent of what we see in any given newspaper will not be there the next day. It is what don’t see that is essential for wrangling the contents of newspapers into shape.

This framework is what we’ll be looking at; some of the invisible rules that hold newspapers together. They are concerned mainly with form, and how readers process information. The parallels with web design will soon become clear, and hopefully the lessons too. Let’s start with an obvious one — above the fold.

Above The Fold

If you’ve worked on the web you’ve likely heard the phrase ‘above the fold,’ meaning the content you’re met with when you land on a web page. It is a newspaper term, and it dates back centuries. Due to their size newspapers are often stacked folded in half, so above the fold literally means the content visible above where they’re folded in half. It is the first thing potential readers see. It is often the one and only chance to make an impression, to get people to buy a copy because they just have to know more. If the newspaper isn’t worth picking up for the front page, what reason is there to think it’s worth picking up at all?

I’d buy that for a dollar! Credit: The New York Times. (Large preview)

The space above the fold is the domain of the lead story, the most important piece of information in the entire paper. It has to hook the reader. This usually equates to big headlines, key pieces of information, and striking imagery. That said, there is not a rigid format. Whatever grabs people’s attention without distorting the truth is on to a winner.

Above the fold is a newspaper’s first and most important answer to ‘the pub test’ — what you’d blurt out if you were telling someone the crux of the story in the boozer. If you had the chance to tell your friends men walked on the moon yesterday, you probably wouldn’t open with the brand of shoes involved. You’d sprint in and yell, “Men have walked on the moon!” That’s above the fold. It’s where newspapers condense the most important story (or stories) of the day to the key points.

The same applies to websites, which no doubt is why the terminology has carried over. ‘Above the fold’ in web design (which online means what you see before scrolling) is the website’s answer to the pub test. What’s the single most important thing people should know? Though this is particularly relevant to home pages, it applies everywhere.

Three guesses what Apple wants you to know about right now. (Large preview)

According to a study of 25 million browsers last year, ‘above the fold’ is comfortably the most viewed part of a web page, with engagement peaking just below. From news to ecommerce to social media, the same principle applies: get to the point.

If you’d like to read more above the fold and front pages generally, Newseum’s Front Page poster is a good place to start.

The Gutenberg Principle

So you’ve grabbed someone’s attention. Congratulations. You’ll need to know about the Gutenberg Principle — or Z-pattern. Championed by ‘the father of newspaper design’ Edmund C. Arnold (more on him later), the Gutenberg Principle is a good rule of thumb to follow when thinking about how people engage with a page of content, be it paper or pixels.

The Gutenberg Principle states that when faced with homogenous content, we start at the top left hand corner and finish at the bottom right hand corner, flicking from right to left as we go. This stems from an idea called reading gravity. We in the western world spend our lives reading from left to right, flicking down and to the left to get to the start of the next line. Newspaper design tends to ape that flow.

The Gutenberg diagram, courtesy of Steven Bradley. (Read his Smashing Magazine article here) (Large preview)

Take the New York Times front page shown earlier for example. Your eyes zig-zag with each line. Where does your eye flick after ‘PLANT FLAG’? Almost certainly to ‘Voice from Moon.’ Breaking this flow tends to be jarring for readers because it’s at odds with a lifetime of reading habits. How often do you see the lead story hugging the right hand side of the page rather than the left? Not often.

The same flow applies to web design. Steven Bradley’s Smashing Magazine article on compositional flow and rhythm explores the principle in an online context, and certainly deserves a read, but I would add that there’s huge value in looking at its application in print. This is a principle that was being applied for decades before the world wide web came along, after all. Any given shortlist of Society for News Design finalists will be a masterclass in content flow. Here are some recent winners to whet your appetite.

Now to be clear, reading gravity isn’t quite as binding as, say, gravity. The eagle eyed among you may have noticed the qualifier that this applies mostly to ‘homogenous’ content. What’s more, it isn’t based on something innate in human nature — it’s guided by language. In languages that read right to left (Arabic for example) the same principle applies, but it is flipped.

Right-to-left languages provide a mirror image of western newspaper layouts. Credit: Tarek Atrissi Design. (Large preview)

This mattered less in the day of print. Papers were generally limited to a geographical region and could reflect the primary language of that region’s audience. In the online realm anyone, anywhere could be visiting your website, so it’s not only valuable to understand the Gutenberg Principle, but to design websites that change shape depending on the language they’re being read in.

(Large preview) Al Jazeera flips its content based on the language it’s viewed in. (Large preview)

The Gutenberg Principle is not the only way people engage with content. Eye tracking studies have shown F-shaped patterns are also common online, for example, with more and more ‘hopping’ the further down the page readers go.

These patterns are all useful to know. They are not rules, just trends. Strong news design does not blindly adhere to the Z-pattern come what may; it uses it as a foundation. The same is true for web design. If in doubt, remember it, but don’t worship it. The human eye has an ingrained reading gravity, but great design leads rather than follows.

The adaptability of the web opens up amazing new possibilities for content presentation. The lessons of the Gutenberg Principle are starting points which can and should be played around with. The best rule breakers usually know exactly what the rules are.

For more information on the Gutenberg Principle follow the links below:


Every newspaper has a nameplate. It’s just about the only thing you can guarantee won’t change from edition to edition. It’s the bit at the top (or very occasionally, along the side) of the front page, and comprises of the publication’s name and logo.

A lot of these are iconic in their own right. The nameplates of publications like The Washington Post and The Sun are seared into the public consciousness. Nameplates are the branding, the bit that says, ‘We’re not that other newspaper. We’re this newspaper.’ It communicates who you are and what you’re about.

It also serves as a kind of directory. Newspapers often have teasers in their nameplates, pointing readers to stories that don’t quite warrant a spot on the front page, but are still worth knowing about. It’s a key player in the above the fold game. Stick around. Keep reading. There’s something here for you. Keeping in mind the Gutenberg Principle, the nameplate is likely the very first thing readers will see.

Newspapers and websites alike understand the value of nameplates for both branding and navigation. (Large preview)

Practically every website has a nameplate, only on websites we call it the header. Smashing Magazine has one, Amazon has one, Facebook has one. It’s weird for a website not to have one, and for it not to appear on every page. On the web every page has to have a bit of the front page about it. A lot of users arrive at a site via the root domain, but a lot don’t.

This is one reason why nameplates online tend to be busier than their print elders. They are able to do more, which is just as well given more is asked of them. But in news and web design the underlying purpose of the nameplate is the same: get the brand front and centre and guide users to something they’ll care about.

Grid Systems And Content Blocks

Newspapers are pure content. From cover to cover, they are packed with information, information which needs to be well organised and well presented. The grid system is foundational to newspaper design. As water shapes itself to a bowl, news content shapes itself to grid systems.

Columns are the most important element of this. Depending on a newspaper’s format (tabloid, broadsheet, etc.) it might have anywhere from four to fourteen columns. It is rare for the content of newspapers not to shape themselves to these columns one way or another. Text flows down a column then resumes in the next one. Images can span multiple columns, especially if they’re eye-catching.

Early publications, like this 1905 edition of Norwegian newspaper Dagbladet, often stuck very closely to their grid systems. (Large preview)

Newspapers have evolved beyond the strangely rigid stream of consciousness affairs you’ll find in earlier efforts like those above. Now it is generally accepted that newspaper content should be organised in blocks, with each story forming its own box. This is called modular layout, and there are several reasons why it is the standard.

First, it is easier to organise. If every story fits in a clean, tidy space, they can be rearranged with relative ease. When you’re trying to fit dozens (or hundreds) of stories into a finite space with the clock ticking, this is a godsend.

Second, it is clearer. Good information is only worth so much when it’s presented badly. Blocks create pages within pages, where each piece of information is distinct and easy to follow.

Modular layout in action in The Guardian. (Large preview)

These standards have always played a role in web design, but they are particularly useful to understand now we have CSS Grid at our disposal. Not only do newspaper grid systems offer guidance for arranging content neatly and clearly, they show how content blocks interact with each other, and with advertising. The wrong alignment can look very silly indeed, while the right arrangement is a joy to read.

As ever, there are differences. For example, online there are rarely jumps (when you reach the bottom of a column and continue reading at the top of the next one) because web pages can go down indefinitely. This kind of layout generally makes less sense online because it leads to readers scrolling up as well as down to get through a single piece of content, which is pretty counterintuitive. As Rachel Andrew demonstrates, jumps can be just the thing for listings and small amounts of content, but the practice is generally a product of print’s physical limitations. The main value of jumps in web design may well be for stacking blocks of content, rather than organising copy.

What’s more, both in print and online abandoning the grid system can be striking in its own right. Just as Dada art recoiled from aesthetic norms of the early 20th century, so do brutalist websites invert the grid system to offer something more… unconventional.

A Dada print by Dutch artist Theo van Doesburg. (Large preview) Yale School of Art sticking it to the man, man. (Large preview)

As noted already, to break the rules first you need to know them. For this and everything else, Tim Harrower’s The Newspaper Designer’s Handbook is a superb place to start. For a more sweeping introduction, Carrie Cousins’ Utilising Grids in Print Design over at Design Shack is excellent.

And how much does this all matter when you move over to the web? Well, more and more. CSS properties like Grid, Shapes, and Flexbox makes it easier than ever to both follow and break the rules of the grid system. Just as newspapers routinely venture outside the invisible lines of their wireframes, so too can websites push the boundaries of their own medium.

In his book Art Direction for the Web, Andy Clarke dives head first into the lessons of print media (and others), showing how advances in CSS can add whole new dimensions to the grid system. As Clarke himself puts it: For years we’ve told each other the web isn’t print. We’ve told ourselves the things we admire in other design media cannot — and sometimes should not — be used online. We needn’t think that anymore.

Hear, hear.

For more inspiration, watch Jen Simmons live code a print layout in CSS Grid at Smashing Conference 2019. Beautiful. And for a more in-depth history of the grid system and its usage, check out this ‘Grids Are Good’ presentation by Khoi Vinh and Mark Boulton.

Look Forward… But Look Backward First

The conventions above were forged by decades — in some cases centuries — of experience, and there’s plenty more where they came from. What they all essentially boil down to is understanding content, and how people are likely to engage with that content.

Newspapers at their best follow a cartoonishly simple principle: present information in ways that are as clear, as attractive, and as accessible as possible. That’s a worthy goal for any website. And don’t take my word for it. These ideas were championed by Edmund C. Arnold, the aforementioned father of modern newspaper design.’ Arnold designed or redesigned hundreds of newspapers during his career, including The Chicago Tribune, The Boston Globe, The National Observer, and Newsday.

Edmund C. Arnold, ‘the father of modern newspaper design.’ Credit: Josh Meltzer/The Roanoke Times. (Large preview)

He pushed for designers to have more influence, for newspapers to have flair as well as substance. He was also a journalist, and an academic, and wrote numerous books about newspaper design and typography. He knew his stuff. It is no coincidence that the Society for News Design (SND), of which he was a founding member in 1992, now holds two awards each year — one for news design, the other for digital.

Anyone keen to learn more about Arnold and his work could do a lot worse than starting with the resources below:

Newspaper designers are students of the web — so too should web designers be students of newspapers. As improvements in web technology open up new frontiers, it pays to know whether someone else has been here before. We are all looking for the same thing, after all. It’s all, fundamentally, the same language.

You can see this playing out in real time as newspapers adapt to the web. The gold standard of news design online at the moment is probably The New York Times, which was a finalist in the print and digital SND awards this year. What’s interesting about the Times online is the blend between classicism and innovation. The homepage still essentially looks like the front page of a print edition, while individual stories, like ‘The Plot to Subvert Democracy’, immerse themselves in the new possibilities of the web.

The New York Times blends best practice of news and web design to make something entirely new. (Large preview)

Or take a newspaper designer like Mario García — part of the generation after Edmund — who’s most recent book, The Story, was designed to be read on mobile phones. The best news designers relish change. The proof is in the pudding. (For those interested, García blogs daily about the overlap of news and web design.)

This, in a lot of ways, is the main takeaway of news design. Its top practitioners are not dogmatists — they are students. When asked at the twilight of his career what his advice was to the next generation of designers, Edmunc C. Arnold’s answer was not a series of rules. It was far simpler than that: know where you came from.

My message to young designers is this: look, kids, you can do better, but the only way to achieve your potential is to go back to — and understand — the basics. That sounds boring, but it’s reality.

Newspapers don’t hold all the keys to great web design, but understanding the principles that guide them can only benefit web designers. There are plenty of kindred spirits in those two worlds. I’m no web designer, but I recognise good web design when I see it in part because of what I know about newspapers. Purpose and style has a way of looking, well, stylish.

Web design guru Jeffrey Zeldman hit the nail on the head when he tweeted this more than a decade ago:

Content precedes design. Design in the absence of content is not design, it's decoration.

— zeldman (@zeldman) May 5, 2008

Vitaly Friedman was bowing to the same altar when he said, “Good design is about effective communication, not decoration at the expense of legibility.” Both he and Zeldman would find plenty of allies in the news design space. Few, if any, mediums have a richer history wedding content and design than newspapers do. That struggle is all they have.

To The As Yet Unimagined

It’s worth reiterating here that there are clear and undeniable differences between news design and web design. In newspapers the dimensions of the space are always the same, while websites must adapt to radically different screen sizes and devices. In newspapers what you see is what you get, while websites can hide all sorts of useful features out of sight until they’re prompted to appear. The aim of this piece is not to convince you that news and web design are the same. They are, however, often very similar. To be master of one does not make you master of the other, but it helps.

Perhaps this is why Friedman collated a selection of award-winning newspaper designs all the way back in 2008. Back then he rued the fact that print techniques weren’t applicable online. Back then CSS wasn’t sophisticated enough. Well, its is now, and that’s really exciting.

The process never ends. It can’t end. No newspaper or website worth its salt is ever truly ‘done.’ It is always evolving. Look at the first ever newspaper and the first ever website and it’s fair to say a lot has changed in both worlds since then:

1609 edition of Relation aller Fürnemmen und gedenckwürdigen Historien, widely considered the first newspaper. (Large preview) The first ever website. (Large preview)

Both formats have improved massively since those humble beginnings, and there’s an awful lot left to achieve. As C. Y. Gopinath traced out beautifully in 2016, the parameters are always changing; web technology, screen sizes, devices, internet speeds, you name it. In the mobile age maybe the nameplate belongs at the bottom. Who knows? It all lies ahead.

In many respects a torch has been passed from news design to web design. If developers can push forward with the knowledge of their elders on hand, they’ll achieve things previous generations couldn’t even have imagined. What an incredible opportunity. I can’t wait to see what they come up with.

(ra, yk, il)
Categories: Design

Meet “Inclusive Components”, A New Printed Book By Heydon Pickering

Thu, 11/07/2019 - 04:30
Meet “Inclusive Components”, A New Printed Book By Heydon Pickering Meet “Inclusive Components”, A New Printed Book By Heydon Pickering Vitaly Friedman 2019-11-07T12:30:00+00:00 2019-11-07T16:07:08+00:00

The web is full of interfaces that leave people out. Of course, it’s not designers’ malicious intent or developers’ lack of empathy that bring us there. It’s just really difficult to foresee a wide range of situations in which our users might find themselves in. We need to build robust and reliable solutions in a world that’s inherently chaotic and unpredictable. Where do we even start?

Because we often build and deploy under tough deadlines, we tend to break accessibility without even noticing it. Our products become slower, clunkier and more painful to use — often simply unbearable for keyboard- and screen reader users, and as such fragile and vulnerable for legal disputes. Let’s fix it.

Meet Inclusive Components, our new handbook for building fully accessible websites and apps.

Heydon Pickering."> Because accessibility matters. We've teamed up with one-and-only Heydon Pickering to create a handbook for building accessible, inclusive interfaces. The eBook is finished, and it's being printed this very moment. About The Book

At its heart, Inclusive Components is a detailed, practical handbook for building fully accessible interfaces. The book examines 12 common interface patterns — accordions, tables, modals, notifications, tabs, toggles, and everything in-between — through the lens of inclusion. The result is accessible and robust components we author, plug in, and use daily.

For years, Heydon Pickering, a seasoned front-end developer with a focus on accessibility, has been writing about accessible solutions. We’ve teamed up with Heydon to produce a book with common challenges and solutions that he’s been refining over all these years.

For each component, the in-depth explorations are meticulously illustrated and all solutions are available as bulletproof code snippets, applicable to your work right away. Bonus: you’ll learn how to build your own accessible components with inclusive design in mind — all in a single book. Jump to table of contents.

332 pages. eBook already available as PDF, ePUB, Amazon Kindle. Printed book will be shipped early December. Written and designed by Heydon. Download a sample PDF (1.1 MB).

Print + eBook { "sku": "inclusive-components", "type": "Book", "price": "39.00", "sales_price": "29.00", "prices": [{ "amount": "39.00", "currency": "USD", "items": [ {"amount": "29.00", "type": "Book"}, {"amount": "10.00", "type": "E-Book"} ] }, { "amount": "39.00", "currency": "EUR", "items": [ {"amount": "29.00", "type": "Book"}, {"amount": "10.00", "type": "E-Book"} ] }, { "amount": "29.00", "currency": "USD", "items": [ {"amount": "22.00", "type": "Book"}, {"amount": "7.00", "type": "E-Book"} ] }, { "amount": "29.00", "currency": "EUR", "items": [ {"amount": "22.00", "type": "Book"}, {"amount": "7.00", "type": "E-Book"} ] } ] } $ 29.00 $ 39.00 Get Print + eBook

Quality hardcover. Free shipping worldwide, starting from early December.

eBook { "sku": "inclusive-components", "type": "E-Book", "price": "18.00", "sales_price": "15.00", "prices": [{ "amount": "18.00", "currency": "USD" }, { "amount": "18.00", "currency": "EUR" }, { "amount": "15.00", "currency": "USD" }, { "amount": "15.00", "currency": "EUR" } ] } $ 15.00 $ 18.00 Free! Get the eBook

DRM-free, of course. ePUB, Kindle, PDF.
Included with Smashing Membership.

Get the eBook

Download PDF, ePUB, Kindle.
Thanks for being smashing! ❤️

Table Of Contents

Each chapter tackles a single component, addressing how different and vulnerable people might read and interact with it, and how they can be better accommodated. Download a sample PDF (1.1 MB).

A preview of the book, with examples ranging from accordions to toggles, tables, notifications, dialogs etc. Download a sample PDF (1.1 MB). Large preview. About The Author

Heydon Pickering (@heydonworks) has worked with The Paciello Group, The BBC, Smashing Magazine, and Bulb Energy as a designer, engineer, writer, editor, and illustrator. He was shortlisted for Designer Of The Year in The Net Awards.

Heydon previously wrote Inclusive Design Patterns which sold over 10,000 copies. Proceeds from this title were donated to the ACLU and The Democratic Socialists Of America, to help these organizations fight fascism and create a more inclusive society.

Testimonials “Inclusive Components is a very deep and thorough explanation of development of accessible components with real world examples. Heydon Pickering shows several alternative approaches and explains pros and cons of each. It’s also a pleasure to read!”

Artem Sapegin, front-end developer, Wayfair “Inclusive Components is chock-full of practical and comprehensive advice on building accessible UI. It’s my go-to resource after the official WCAG and ARIA documentation. I’ve found it extremely helpful when building our design system!”

Sarah Federman, senior front-end developer, Adobe “What Heydon achieves with his work on Inclusive Components is a pragmatic, friendly and approachable set of guides that help you to generate not just accessible components, but also resilient and progressive starting-points that will help you to build better websites and web apps in general. I often describe this work as crucial learning material for this exact reason.”

Andy Bell, independent designer & developer Why This Book Might Be For You

The devil is in the detail and often the things you do with good intentions can impose accessibility barriers unknowingly. Inclusive Components is for every front-end developer who wants to learn how to detect and address potential accessibility issues in their work. The book will teach you:

  1. How to use <button> elements, how to apply styles to your toggle buttons, and how to label them.
  2. How to create managed lists that allow users to create and delete content — in an inclusive way.
  3. How to address and resolve accessibility issues with navigation menus and submenus (aka “dropdowns”).
  4. How to create accessible and keyboard-friendly tooltips and toggletips.
  5. How to create a “dark mode” theme that’s both accessible and maintainable long-term.
  6. How to build an accessible content slider to prevent harm for motion-sensitive people.
  7. How to create inclusive notifications with live regions to communicate with your users through visual and aural channels simultaneously.
  8. How to create data tables that are semantically correct, responsive, and sortable.
  9. How to build accessible dialogs and modal dialogs with performance and inclusive design in mind.
  10. How to create and group inclusive cards (e.g. for teasers).
Technical Details Community Matters ❤️

With Inclusive Components, we've tried to create a very focused handbook with applicable, long-living solutions and strategies to create accessible and inclusive interfaces.

Our hope is that with Heydon's book, you will be able to make better design and coding decisions as you build your interfaces. Perhaps it will even become one of those reference books you'll reach to every time you need to build one of those common UI components.

Producing a book takes quite a bit of time, and we couldn't pull it off without the support of our wonderful community. A huge shout-out to Smashing Members for their ongoing support in our adventures. As a result, the eBook is and always will be free for Smashing Members. Plus, Members get a friendly discount when purchasing their printed copy.

Stay smashing, and thank you for your ongoing support, everyone!

Print + eBook { "sku": "inclusive-components", "type": "Book", "price": "39.00", "sales_price": "29.00", "prices": [{ "amount": "39.00", "currency": "USD", "items": [ {"amount": "29.00", "type": "Book"}, {"amount": "10.00", "type": "E-Book"} ] }, { "amount": "39.00", "currency": "EUR", "items": [ {"amount": "29.00", "type": "Book"}, {"amount": "10.00", "type": "E-Book"} ] }, { "amount": "29.00", "currency": "USD", "items": [ {"amount": "22.00", "type": "Book"}, {"amount": "7.00", "type": "E-Book"} ] }, { "amount": "29.00", "currency": "EUR", "items": [ {"amount": "22.00", "type": "Book"}, {"amount": "7.00", "type": "E-Book"} ] } ] } $ 29.00 $ 39.00 Get Print + eBook

Quality hardcover. Free shipping worldwide, starting from early December.

eBook { "sku": "inclusive-components", "type": "E-Book", "price": "18.00", "sales_price": "15.00", "prices": [{ "amount": "18.00", "currency": "USD" }, { "amount": "18.00", "currency": "EUR" }, { "amount": "15.00", "currency": "USD" }, { "amount": "15.00", "currency": "EUR" } ] } $ 15.00 $ 18.00 Free! Get the eBook

DRM-free, of course. ePUB, Kindle, PDF.
Included with Smashing Membership.

Get the eBook

Download PDF, ePUB, Kindle.
Thanks for being smashing! ❤️

Categories: Design

Inclusive Design And Accessibility: Live Stream With Heydon Pickering

Thu, 11/07/2019 - 03:45
Inclusive Design And Accessibility: Live Stream With Heydon Pickering Inclusive Design And Accessibility: Live Stream With Heydon Pickering Vitaly Friedman 2019-11-07T13:45:59+02:00 2019-11-07T13:15:30+00:00

Accessibility can sometimes become an unfortunate afterthought as we race to meet deadlines and search for tips and tricks to meet client demands. We can cause problems for keyboard or screenreader users, and leave our products fragile and potentially vulnerable to legal action from people who find themselves locked out due to their accessibility needs. How can we get better?

One way to find out would be by joining our live stream with Heydon Pickering who will be sharing insights about the relationship between accessibility and design systems, and exploring how to build accessible components, and why he decided to write a book on accessible interface design patterns.

Live Stream On Inclusive Design: Nov 7, 5:00 PM GMT

The session will start today, November 7, at 6:00 PM Berlin time (1:00 PM New York time) — broadcasted live below!

For a few years now, we’ve been running live sessions with respected professionals on Smashing TV — our video channel for our dear Smashing Members, who support our little team and our little adventures every month.

Starting from November, we’d like to try out something new. As the webinars have always been about sharing lessons learned with the community, we’d like to open them up to everybody, with Members having a chance to ask questions about the projects and their work right after the session.

From Smashing With Love

To help you stay on top of things, you can subscribe to our bi-weekly newsletter in which we announce what’s happening in the Smashing universe. Each and every newsletter issue is written and edited with love and care. No third-party mailings or hidden advertising — promise!

You can also follow us on Twitter, Facebook, LinkedIn and even stay updated with our bi-weekly Smashing Podcast. Please do always feel free to reach out and share your thoughts with us — we love hearing from you!

(ra, il)
Categories: Design

Exploring New Ways To Manage Content In WordPress

Thu, 11/07/2019 - 01:30
Exploring New Ways To Manage Content In WordPress Exploring New Ways To Manage Content In WordPress Leonardo Losoviz 2019-11-07T11:30:59+02:00 2019-11-07T13:15:30+00:00

The combination of WordPress’ versatility for managing data (since its database model supports the creation of different content models, easily extensible through meta attributes) and Gutenberg’s rich user interactions provide a powerful mechanism to create, edit and manage content.

In this article, I want to shine some light on these upgraded capabilities, exploring the new tools at our disposition and presenting several new ones to be released sometime in the future.

Existing Features

The following features are already part of Gutenberg-powered WordPress.

Create Once, Publish Everywhere

As I have described in my recent article “Create Once, Publish Everywhere” with WordPress, the block-based nature of Gutenberg enables it to enhance how content is organized/architected on the database, making it available on a granular basis (block by block) to any application running on any medium or platform (web, email, iOS/Android apps, VR/AR, home assistants, and so on). Content managed through Gutenberg can then become the single source of truth for all of our applications, allowing us to reduce the cost associated with re-formatting content to make it suitable for each required platform.

Copy/paste from Google Docs with (almost) perfect formatting

Whenever we need to collaborate with other people to create content, we will quite likely use online tools such as Google Docs, Dropbox Paper, Coda or others. These tools make it easy for different people to edit the content in a document concurrently and provide and incorporate feedback. If we are going to choose a Content Management System to store our content, we need to make sure that it works well with these tools.

Gutenberg does the job fairly well: When copying the content from a Google Doc and then pasting it into a Gutenberg blog post, the formatting is preserved, bullet lists are properly transformed to the list block, and images are inserted where they should. There may be a few inconsistencies (for instance different spacing across blocks and in the original document) however, for the most part, the process is fit for use.

Copy/pasting from GDoc preserves the format of the document. (Large preview) Crafting art direction

Several Gutenberg blocks support creating distinctive and engaging layouts and assisting the art direction of the site, to give it more personality and emphasize its identity. This way, even though we may base the site on a standard, plain-looking WordPress theme, we can customize the content’s appearance to make it stick out from the sea of sameness out there on the web. Let’s explore some of these blocks.

The Shape divider block allows to insert dividers in between two blocks. We can choose one among several basic shapes and customize its width, proportions and colors and then, with a bit of resourcefulness, create more intrinsic patterns from it. For instance, the divider below was created by first creating and customizing a divider, then flipping it both vertically and horizontally to mirror itself, then grouping these 2 halves so we can use it as a single unit (the grouping functionality will be available in core through the release of WordPress 5.3 next week, and is currently available through the Gutenberg plugin), and finally saving the grouped block as a reusable block so it can be used everywhere across the whole site:

The shape divider block connects, or breaks apart, components. (Large preview)

The Advanced columns and Row layout blocks allow to create row-based layouts, inside of which we can place nested blocks (i.e. any other Gutenberg block). They are highly configurable: They offer to define how many columns the row must have, with what padding, margin and proportion of width for each column, setting an image or custom color in the background, and several other attributes.

The row layout block allows to easily configure the proportion of width among columns. (Large preview)

We can also create grid-based layouts with predefined content. For instance, through the Post grid, Post carousel and Post masonry blocks we can display a list of posts in different ways, defining what attributes from each post to show (title, date, excerpt, author, and so on), and through the Advanced gallery block we can create beautiful image galleries.

Masonry gallery created with Advanced gallery block. (Large preview)

Some other blocks, such as Feature grid, allow to create grid layouts with predefined templates filled with custom content.

The feature grid block enables to add custom content inside of a grid layout. (Large preview)

These are just a sample of those blocks which can help us fill the content with visually attractive layouts and craft the art direction of our sites. To keep exploring possibilities, we can head to the directory of plugins offering blocks and check these out.

Assisting the user while editing content

Gutenberg assists the user when creating content through the following features:

Real-Time Preview

The Gutenberg editor gives a relatively accurate preview of how the content will look like in the website.

Error Warnings

Gutenberg makes the content creator be aware of accessibility concerns. For instance, if our content structure jumps from an <h2> header to an <h4> one without adding an <h3> tag in between, Gutenberg provides a warning message about this potential error. Similarly, when setting up the color of some text against its background color, if the contrast between the two colors is not clear enough then Gutenberg provides a warning message and helps fix the problem.

Suggesting/Executing Improvements

Blocks can connect to third-party services to analyze content and enhance it. For instance, a service could suggest how to improve the grammar of the content, provide alternative titles and tags for a better SEO, and even automatically translate the content to another language, as done by this plugin which automatically translates from English to Hindi as the user types.

New Features Under Implementation

The following features will hopefully/eventually be coming to Gutenberg in the future.

Snap to grid when resizing images

Contributors are already working on adding a grid system to Gutenberg which will, among other things, enable to resize images in an assisted manner by snapping it to the grid:

Snapping an image to grid (image from the GitHub issue). (Large preview) Inline installation of blocks

Sometimes, while we are writing a blog post, we find out that we need some functionality that we don’t have yet installed. Hence, we need to switch to the Plugins screen, search and install the corresponding plugin, and then go back to the blog post. This process adds friction to our content-writing workflow.

Wouldn’t it be nicer if we could install the required functionality right from within the editor itself, whenever we need to use it? Well, this proposal is already being implemented through this pull request (it first depends on blocks being installed on their own, i.e. without depending on being shipped through a plugin). Once merged, our content-writing workflow will not be impaired anymore, as visible in the mockup below.

Installing a block from within Gutenberg (image from the GitHub pull request). (Large preview)

Installing blocks directly from the editor could lead to unintended bloat, from making it too easy for the user to install blocks. To address this issue, after installing and using it, the block could be removed! This was not possible before Gutenberg, because if the plugin providing a shortcode (which was the way to render dynamic content inside the blog post before Gutenberg) was disabled, then the invocation of the shortcode would be rendered in the blog post (instead of the shortcode’s output), messing up our content. However, Gutenberg works differently: Blocks only save HTML content inside of the blog post (including HTML comments to store configuration attributes), so, if the block is disabled, its intended HTML output is still part of the blog post’s content. (Even though there may be problems if the block needs to load CSS assets which are not loaded anymore once the block is disabled. I am not aware how this issue will be handled.)

Page/Site builder

Currently Gutenberg can only be used for the creation of content inside a blog post or a page, however it will soon support the creation of any part of the website: Content-block areas can define the header, sidebars, footer or any section needed for our layouts. Automattic (the company behind is already working on a plugin to add full site editing capabilities to its product, which should eventually be extensible to the open source WordPress software too.

Creating a new page with full site editing allows to select a page template. (Large preview) Real-time collaboration

Google Docs is incredibly useful to teams because it enables their members to work on the same document at the same time. Sometime in the future, Gutenberg will also incorporate a mechanism for real-time collaboration, allowing different people to work on the same blog post at the same time. This mechanism will (at least initially) be based on giving editing-locks to users on a block-by-block basis, as shown in the mockup image below.

Real-time collaboration through Gutenberg (image from the GitHub issue). (Large preview)

This feature will be particularly useful to online magazines (such as the New York Times and the like) since they may already have teams collaborating on a story (for instance, designers dealing with images, journalists, proofreaders and editors dealing with content, and others). Having real-time collaboration tools will enable these magazines to speed up their content-creation workflows and publish their articles faster.


WordPress core has never added support to translate content (it only supports translation of strings inside of core, plugin and theme files), but instead left this responsibility to plugins. Through Gutenberg, WordPress will finally add native support for this feature.

Translation is not a priority yet, so it has been targeted for Gutenberg phase 4, expected in the year 2020+. Since it is a long way off, there are yet no technical considerations of its implementation or mockups of its intended user experience. So we can only guess how it will be. Since it will be implemented after the real-time collaboration feature (described above), I would expect it will enable different people to translate the same blog post to different languages at the same time, block by block.

Inline media editing

Through the Media Library, WordPress already provides some image editing capabilities: resizing, cropping, rotating and flipping. These capabilities are very basic, and they are applied on to the image on a different screen, which creates some friction to the process of fitting the image into the blog post.

Through Gutenberg, the media-editing experience could be greatly enhanced: One one side, it could support editing the image in more advanced ways, such as applying effects or filters, altering the contrast, replacing colors, adding text as watermark, adding transparent regions, converting it to different formats, and others (for instance, Cloudinary provides an API to apply many transformations to an image, which could be perfectly accessed by a block). On the other side, the editing could happen inline, right where the image is placed inside the blog post. Then, for instance, if the image was added as an overlay against some background, and we add transparent regions to the image, we can visualize in real-time how the composite result looks like.

(I haven’t found any proposal to tackle this issue in Gutenberg’s GitHub repo, but I learned about this idea talking to some core contributors, who expected to be able to work on it some time in the future.)


Already being the most popular CMS (close to 35% of the web), WordPress has also the chance to offer the most compelling tools to manipulate content. This is because Gutenberg offers an appealing mechanism to create, edit and manage content: A single interface, simple to use, fairly powerful and versatile. With its new content management capabilities, WordPress can become the single source of truth of all our content, to power all our applications (websites, newsletters, apps, and so on) through APIs. Kudos to that!

(yk, il)
Categories: Design

Writing A Multiplayer Text Adventure Engine In Node.js: Adding Chat Into Our Game (Part 4)

Wed, 11/06/2019 - 01:00
Writing A Multiplayer Text Adventure Engine In Node.js: Adding Chat Into Our Game (Part 4) Writing A Multiplayer Text Adventure Engine In Node.js: Adding Chat Into Our Game (Part 4) Fernando Doglio 2019-11-06T11:00:00+02:00 2019-11-06T13:06:52+00:00

Any platform that allows for collaborative play between people will be required to have one very particular characteristic: the ability for players to (somehow) talk to each other. That is exactly why our text-adventure engine built in Node.js would not be complete without a way for the party members to be able to communicate with each other. And because this is indeed a text adventure, that form of communication will be presented in the form of a chat window.

So in this article, I’m going to explain how I added chat support for the text client as well as how I designed a quick chat server using Node.js.

Previous Parts Of This Series

  • Part 1: The Introduction
  • Part 2: Game Engine Server Design
  • Part 3: Creating The Terminal Client

Back To The Original Plan

Lack of design skills aside, this has been the original wireframe/mock-up for the text-based client we built in the previous part of the series:

(Large preview)

The right side of that image is meant for inter-player communications, and it’s been planned as a chat since the beginning. Then, during the development of this particular module (the text client), I managed to simplify it into the following:

(Large preview)

Yes, we already covered this image in the previous installment but our focus was the left half. Today, however, our focus will be on the right half of what you’re seeing there. In other words:

  • Adding the ability to reactively pull data from a third-party service and update a content window.
  • Adding support to the command interface for chat commands. Essentially changing the way commands work out of the box and adding support for things, such as “sending a message to the rest of the team”.
  • Create a basic chat server on the back-end that can facilitate team communication.

Let me start with the last one before moving on to how to modify our existing code.

Creating The Chat Server

Before even looking at any code, one of the first things one should do is to quickly define the scope of any new project. Particularly with this one, we need to make sure we don’t spend a lot of time working on features we might not need for our particular use case.

You see, all we need is for the party members to be able to send messages with each others, but when one thinks of a “chat server”, other features often come in mind (such as chat rooms, private messages, emojis and so on).

So in order to keep our work manageable and get something out that works, here is what the chat server module will actually do:

  • Allow for a single room per party. Meaning, the actual room for a party will be auto-created when the game itself is created and the first player starts playing. All subsequent party members will join the same room, automatically and without a choice.
  • There will not be support for private messages. There is no need to be secretive in your party. At least not in this first version. Users will only be able to send messages through the chat, nothing else.
  • And to make sure everyone is aware, the only notification sent to the entire party, will be when new players join the game. That’s all.

The following diagram shows the communication between servers and clients. As I mentioned, the mechanics are quite simple, so the most important bit to highlight here is the fact that we’re keeping conversations contained within the same party members:

(Large preview) The Tools For The Job

Given the above restrictions and the fact that all we need is a direct connection between the clients and the chat server, we’ll solve this problem with an old fashion socket. Or in other words, the main tool we’ll be using is (note that there are 3rd party services providing managed chat servers, for instance, but for the purposes of this, going there would the equivalent of killing a mosquito with a shotgun).

With we can establish a bidirectional, real-time, event-based communication between the server and the clients. Unlike what we did with the game engine, where we published a REST API, the socket connection provides a faster way of communication.

Which is exactly what we need, a quick way to connect clients and server, exchanging messages and sending broadcasts between them.

Designing A Chat Server

Although is quite magical when it comes to socket management, it’s not a full chat server, we still need to define some logic to use it.

For our particularly small list of features, the design of our server’s internal logic should look something like this:

  • The server will need to support at least two different event types:
    1. New message
      This one is obvious, we need to know when a new message from a client is received, so we’ll need support for this type of event.
    2. New user joined
      We’ll need this one just to make sure we can notify the entire party when a new user joins the chat room.
  • Internally, we’ll handle chat rooms, even though that concept will not be something public to clients. Instead, all they will send is the game ID (the ID players use to join the game). With this ID we’ll use’s rooms feature which handles individual rooms for us.
  • Because of how works, it keeps an in-memory session open that is automatically assigned to the socket created for each client. In other words, we have a variable automatically assigned to each individual client where we can store information, such as player names, and room assigned. We’ll be using this socket-session to handle some internal client-room associations.
A Note About In-Memory Sessions

In-memory storage is not always the best solution. For this particular example, I’m going with it because it simplifies the job. That being said, a good and easy improvement you could implement if you wanted to take this into a production-ready product would be to substitute it with a Redis instance. That way you keep the in-memory performance but add an extra layer of reliability in case something goes wrong and your process dies.

With all of that being said, let me show you the actual implementation.

The Implementation

Although the full project can be seen on GitHub, the most relevant code lies in the main file (index.js):

// Setup basic express server let express = require('express'); let config = require("config") let app = express(); let server = require('http').createServer(app); let io = require('')(server); let port = process.env.PORT || config.get('app.port'); server.listen(port, () => { console.log('Server listening at port %d', port); }); let numUsers = 0; io.on('connection', (socket) => { let addedUser = false; // when the client emits 'new message', this listens and executes socket.on(config.get(''), (data, done) => { let room = socket.roomname if(!socket.roomname) { socket.emit(config.get(''), "You're not part of a room yet") return done() } // we tell the client to execute 'new message'''), { room: room, username: socket.username, message: data }); done() }); socket.on(config.get(''), (data, done) => { console.log("Requesting to join a room: ", data) socket.roomname = data.roomname socket.username = data.username socket.join(data.roomname, _ => {''), { username: 'Game server', message: socket.username + ' has joined the party!' }) done(null, {joined: true}) }) }) // when the user disconnects.. perform this socket.on('disconnect', () => { if (addedUser) { --numUsers; // echo globally that this client has left'user left', { username: socket.username, numUsers: numUsers }); } }); });

That is all there is for this particular server. Simple right? A couple of notes:

  1. I’m using the config module to handle all my constants. I personally love this module, it simplifies my life every time I need to keep “magic numbers” out of my code. So everything from the list of accepted messages to the port the server will listen to are stored and accessed through it.
  2. There are two main events to pay attention to, just like I said before.
    • When a new message is received, which can be seen when we listen for config.get(''). This code also makes sure you don’t accidentally try to send a message before joining a room. This shouldn’t happen if you implement the chat client correctly, but just in case these type of checks are always helpful when others are writing the clients for your services.
    • When a new user joins a room. You can see that event on the config.get('') listener. In that case, all we do is add the user to the room (again, this is handled by, so all it takes is a single line of code) and then we broadcast to the room a message notifying who just joined. The key here is that by using the socket instance of the player joining, the broadcast will be sent to everyone in the room except the player. Again, behavior provided by, so we don’t have to add this in.

That is all there is to the server code, let’s now review how I integrated the client-side code into the text-client project.

Updating The Client Code

In order to integrate both, chat commands and game commands, the input box at the bottom of the screen will have to parse the player’s input and decide on what they’re trying to do.

The rule is simple: If the player is trying to send a message to the party, they’ll start the command with the word “chat”, otherwise, they won’t.

What Happens When Sending A Chat Message?

The following list of actions takes place when the user hits the ENTER key:

  1. Once a chat command is found, the code will trigger a new branch, where a chat client library will be used and a new message will be sent (emitted through the active socket connection) to the server.
  2. The server will emit the same message to all other players in the room.
  3. A callback (setup during boot-time) listening for new events from the server will be triggered. Depending on the event type (either a player sent a message, or a player just joined), we’ll display a message on the chat box (i.e the text box on the right).

The following diagram presents a graphic representation of the above steps; ideally, it should help visualize which components are involved in this process:

(Large preview) Reviewing The Code Changes

For a full list of changes and the entire code working, you should check the full repository on Github. Here, I’m quickly going to glance over some of the most relevant bits of code.

For example, setting up the main screen is where we now trigger the connection with the chat server and where we configure the callback for updating the chat box (red box on the top from the diagram above).

setUpChatBox: function() { let handler = require(this.elements["chatbox"].meta.handlerPath) handler.handle(this.UI.gamestate, (err, evt) => { if(err) { this.UI.setUpAlert(err) return this.UI.renderScreen() } if(evt.event == config.get('chatserver.commands.JOINROOM')) { this.elements["chatbox"].obj.insertBottom(["::You've joined the party chat room::"]) this.elements["chatbox"].obj.scroll((config.get("screens.main-ui.elements.gamebox.autoscrollspeed") ) + 1) } if(evt.event == config.get('chatserver.commands.SENDMSG')) { this.elements["chatbox"].obj.insertBottom([evt.msg.username + ' said :> ' + evt.msg.message]) this.elements["chatbox"].obj.scroll((config.get("screens.main-ui.elements.gamebox.autoscrollspeed") ) + 1) } this.UI.renderScreen() }) },

This method gets called from the init method, just like everything else. The main function for this code is to use the assigned handler (the chatbox handler) and call it’s handle method, which will connect to the chat server, and afterwards, setup the callback (which is also defined here) to be triggered when something happens (one of the two events we support).

The interesting logic from the above snippet is inside the callback, because it’s the logic used to update the chat box.

For completeness sake, the code that connects to the server and configures the callback shown above is the following:

const io = require(''), config = require("config"), logger = require("../utils/logger") // Use https or wss in production. let url = config.get("chatserver.url") let socket = io(url) module.exports = { connect2Room: function(gamestate, done) { socket.on(config.get('chatserver.commands.SENDMSG'), msg => { done(null, { event: config.get('chatserver.commands.SENDMSG'), msg: msg }) }) socket.emit(config.get("chatserver.commands.JOINROOM") , { roomname: gamestate.gameID, username: gamestate.playername }, _ => {"Room joined!") gamestate.inroom = true done(null, { event: config.get('chatserver.commands.JOINROOM') }) }) }, handleCommand: function(command, gamestate, done) {"Sending command to chatserver!") let message = command.split(" ").splice(1).join(" ")"Message to send: ", message) if(!gamestate.inroom) { //first time sending the message, so join the room first"Joining a room") let gameId = socket.emit(config.get("chatserver.commands.JOINROOM") , { roomname: gamestate.gameID, username: gamestate.playername }, _ => {"Room joined!") gamestate.inroom = true updateGameState = true"Updating game state ...") socket.emit(config.get("chatserver.commands.SENDMSG"), message, done) }) } else {"Sending message to chat server: ", message ) socket.emit(config.get("chatserver.commands.SENDMSG"), message, done) } } }

The connect2room method is the one called during setup of the main screen as I mentioned, you can see how we set up the handler for new messages and emit the event related to joining a room (which then triggers the same event being broadcasted to other players on the server-side).

The other method, handleCommand is the one that takes care of sending the chat message to the server (and it does so with a simple socket.emit). This one is executed when the commandHandler realizes a chat message is being sent. Here is the code for that logic:

module.exports = { handle: function(gamestate, text, done) { let command = text.trim() if(command.indexOf("chat") === 0) { //chat command chatServerClient.handleCommand(command, gamestate, done) } else { sendGameCommand(gamestate, text, done) } } }

That is the new code for the commandHandler, the sendGameCommand function is where the old code now is encapsulated (nothing changed there).

And that is it for the integration, again, fully working code can be downloaded and tested from the full repository.

Final Thoughts

This marks the end of the road for this project. If you stuck to it until the end, thanks for reading! The code is ready to be tested and played with, and if you happen to do so, please reach out and let me know what you thought about it.

Hopefully with this project, many old-time fans of the genre can get back to it and experience it in a way they never did.

Have fun playing (and coding)!

Further Reading on SmashingMag: (dm, yk, il)
Categories: Design

Smashing Podcast Episode 2 With Liz Elcoate: What’s So Great About Freelancing?

Tue, 11/05/2019 - 06:00
Smashing Podcast Episode 2 With Liz Elcoate: What’s So Great About Freelancing? Smashing Podcast Episode 2 With Liz Elcoate: What’s So Great About Freelancing? Drew McLellan 2019-11-05T16:00:59+02:00 2019-11-05T15:45:22+00:00

In this episode of the Smashing Podcast we take a look a freelancing. What does it mean to be a freelance designer or developer? How do you structure your day? What are the ups and downs? Drew McLellan talks to experienced freelance brand designer Liz Elcoate to find out more.

Show Notes Transcript

Drew: She’s a UK based designer who specializes in building digital brands. She’s worked on campaigns with the likes of Great Ormond Street Hospital, the NSPCC, and the Brits. She’s also the host of The Elastic Brand podcast, all about digital brand design, and co-host of The Freelance Web, a podcast for freelancers working on the web.

Drew: We know she loves design and she loves podcasts, but did you know she once felled a tree using nothing but a mango? My smashing friends, please welcome Liz Elcoate.

Liz Elcoate: Hello, hi.

Drew: How are you?

Liz Elcoate: Do you know what, Drew? I’m smashing.

Drew: Of course you are.

Liz Elcoate: Nailed it.

Drew: I wanted to chat about freelancing with you today.

Liz Elcoate: Great.

Drew: You’re a freelance digital brand designer. Is that how you’d describe yourself?

Liz Elcoate: I think I was trying to start the term digital brand designer, but I realize now they’re just brand designers. I probably now just go by the term brand designer. Everyone was like, “What, a digital what?” I do brands that work both online and off now.

Drew: You don’t pigeonhole yourself exclusively to online stuff?

Liz Elcoate: No. I tend to work with a lot of agencies that are maybe tech agencies, digital agencies. Most of their branding would appear online. They’re not going to have huge offline print, billboards, and things like that. A good brand should work everywhere.

Drew: What does the day of a digital brand designer look like?

Liz Elcoate: Oh God, the truth or the …

Drew: If was to pack up my bags, move to a remote part of Scotland … I’m thinking maybe an island in Scotland. I’ll take my cat. I say I’m going to be a digital brand designer. I’d wait typically six to eight weeks for my broadband to get installed.

Liz Elcoate: Then it’d be rubbish, wouldn’t it?

Drew: Then it would be absolutely terrible. What would my day look like as a freelancer doing the sort of work that you do?

Liz Elcoate: Well, I guess I always start my day off with a dog walk, so you might start yours off with a cat walk possibly. A good dog walk out in the open air always gets me set up for the day. Then back to my desk, check emails, answer emails.

Liz Elcoate: I tend to do the creative work in the morning, because I just find that’s when I work best. I’ll do a couple of hours of really focused creative work. I’ll turn off my phone, turn off my email, and just really get my head down. I can achieve so much in that period of time, probably more than I would do later on in the day for a longer period of time.

Liz Elcoate: I do that, and then maybe check emails again, lunch, get away from my desk for a little while, and then the afternoon will be tidying up whatever has come in the morning, maybe writing for a magazine, maybe Smashing Magazine, or writing proposals, or planning workshops, stuff like that.

Liz Elcoate: The really creative stuff happens in the morning, and the writing and stuff happens in the afternoon, and also do a bit of admin in the afternoon as well. I’m one of those weird people who love admin. I’m so weird. I do tend to quite enjoy that.

Liz Elcoate: It’s just because it’s like math, there’s an answer, whereas I find the creative, it can be draining because it’s so open-ended.

Drew: I guess that’s one of the differences between doing freelance creative work and freelance technical work.

Liz Elcoate: Absolutely. Also, on the very rare occasions I actually code anything these days … and that’s never for clients. That’s only for personal work … is a joyous time, because there’s a right and a wrong way to do. I’m sure there’s lots of people out there who’d say, “Well, there’s many right ways to do these things.” With my knowledge, you do something and you have an answer. It’s so nice. It’s a real break from the creative.

Liz Elcoate: I did a workshop a couple of weeks ago in Ireland. It was a new workshop that I’ve not done before. It was five hours. It was a brand workshop, and I needed to really make sure that I answered all the questions that I needed answering, as well as making it engaging for the nine or 10 people who are involved in it, and relevant for them and fun as well.

Liz Elcoate: I loved writing it, but it wasn’t until that moment that I actually delivered it to them, and we got to the 2:00 PM mark and it was all over. I thought, “Actually, that worked out.” It was, again, that kind of like, “I’m not sure how this is going to go.”

Liz Elcoate: I think that’s the same with the design side of what I do. It’s, “Well, we’ll find out how successful this has been when we hear back from them.” It can be really draining. I think that’s why I really enjoy the admin side of things, and also writing as well seems to be more formulaic, and I have a little bit more confidence, I guess, doing that. I’m confident in what I do for a living, but you don’t know until that moment the client comes back to you.

Drew: You mentioned spending time writing proposals as one of the things you do in your afternoons. How much of your time is taken up in responding to proposals, and calling clients, and finding new work?

Liz Elcoate: Well, at the moment, a lot more than it used to be. I try to be a lot more proactive around those things now. I think it’s a challenge as a brand designer. It’s not quite as straight forward, I think, as with other parts of our industry, because branding is often a really big project for a company, and they don’t do it regularly.

Liz Elcoate: It’s not like, “We need updates to our site,” or “We want to change this part of our site,” or whatever. It’s sort of like, “We’ve had the same brand for four years, five years. We need an overhaul,” or “We’re a startup …” It’s a big decision for people.

Liz Elcoate: I’m not constantly bombarded with inquiries, but when people do inquire, it often means that they’re very serious about it and it’s a big financial commitment for them as well. It can be quite a traumatic experience for them, because they think they’re one thing, and they’re now discovering that they’re maybe something else.

Liz Elcoate: The proposals, to me, I probably write one or two every week or fortnight, but I really take time with them. They take me a couple of days, a couple of afternoons to write. I used to just bang out a quick proposal, just outlining what they need and what I can do for them, but I think a lot of people do that. It doesn’t set you apart.

Liz Elcoate: I was going to work with Christopher Murphy on a project, and he, in the end, didn’t end up coming in on the project, but we wrote a proposal together, and he just completely changed the way I wrote proposals. He changed them so professionally, really engaged the client and their needs. From that moment onwards, I was writing them like that.

Liz Elcoate: Anyone else who’s seen my proposals, if I bring in other people into projects, they’ll be like, “Wow, your proposal is a game changer.” I’m like, “Well, I can’t take any credit for that.” It really has made a difference. When I write them, I really make a concerted effort to make sure that they are very, very pertinent to that particular client.

Drew: Then do you send them off and hope for the best, or do you talk through on a call?

Liz Elcoate: If we’ve got to a proposal stage (because they’re a time-consuming commitment), I feel that I’ve got to a point where they’re very committed to me and maybe one or two other people. I know they’re not just fishing around a whole group of people, and we’ve probably had a video call by then as well.

Liz Elcoate: I’ll send the proposal over and I’ll say we can schedule a call to have a chat through. Sometimes they want to do that, and sometimes they’re like, “No, it’s fine. Don’t worry.” Then they just come back to me like a week later like, “Yes, great.”

Liz Elcoate: I tend to find that if I haven’t heard from them within a week, they’re not probably going to go with me. That’s always quite a red flag. If they come back three weeks later or a month later and say, “We want to work with you,” I think, “Okay, that’s taken a very long time. What’s this project going to pan out like if that’s how long it takes you to make that kind of decision?”

Liz Elcoate: Generally we have a chat through on a video call once that’s gone over.

Drew: I know from stuff I’ve done in the past, the turnaround time can really vary, can’t it, between you can have people who take a couple of hours to read through what you’ve sent and respond straight away, and sometimes you think a project is completely gone away, and then three months later-

Liz Elcoate: Yeah, I had one of those recently, actually. I had a really quite serious inquiry. Basically, they were like, “Yes, we want to go with you. Can you just put a proposal together?” I put the proposal together, sent it over, didn’t hear from them, chased them up, didn’t hear from them again, chased them up again.

Liz Elcoate: It was a good five weeks, and I thought, “Well I’ve not heard from them. This is definitely not going to happen. It’s a shame.” My email’s always very polite, but it said, “Just let me know if you don’t want to go with me, just so I know. Any feedback would be great.” Didn’t hear anything. They came back out of the blue not long ago and said, “Sorry, just being really busy.” You’re like, “Wow, oh my God.”

Liz Elcoate: I think as a freelancer, when you’re on your own, stuff comes in, you react to it, so you expect other people to work like that. I find when I work with maybe a company of one or a small agency, they do react really quickly. They don’t need to take time to think of stuff, but when I work with big agencies, they often take a good week.

Liz Elcoate: You have the person in charge of the project, but then they need to then go off to their stakeholders and have a chat with them about everything. They’re already busy, so they need to schedule a meeting, and it tends to be a bit longer. There’s no hard and fast rules, unfortunately.

Drew: Other than the more stakeholders there are involved, the longer everything is going to take.

Liz Elcoate: If there’s more than maybe two or three stakeholders involved, I’m always slightly dubious about the whole situation. I had one not long ago, and there was a board of 10 people involved in deciding about the direction the brand was going to go. It was just a long, painful, drawn-out process.

Liz Elcoate: They were a very mixed age group as well, and very different backgrounds, and it was as expected when that kind of thing happens.

Drew: I once did a project for a law firm partnership, where everyone in the law firm, there were about a dozen people who were all equal partners, obviously very bright, switched on people with their own opinions about how everything should go.

Drew: We managed to get the site developed, and it failed at the final hurdle of signing it off because they couldn’t get all 12 people to sign off, and it just never launched. Completely-finished website, and it just never launched.

Liz Elcoate: That is so sad. I always do try and say to clients that you need to have someone take the lead on it, and someone who can say to even the stakeholders, “Look, we’ve got to have a decision on this,” because it is impossible.

Liz Elcoate: I think when I used to work for the agency that I used to work for, we worked with a lot of schools. We’d sometimes have a board of governors involved, as well as the head-teacher, as well as three or four teachers who wanted to be involved as well.

Liz Elcoate: They were hugely different age ranges and experience. Those projects were the same as yours. It’s almost impossible to sign off in the end.

Drew: You’ve got a good number of years experience doing this, like me.

Liz Elcoate: I’m old. I’m old.

Drew: It’s a euphemistic way of, “Yes, we have a lot of experience in our respective fields.”

Liz Elcoate: Definitely.

Drew: Have you always been freelance, or did something come before that?

Liz Elcoate: Gosh, if we go back to the dawn of time, which is when I began my career, I worked for an Australian bank way back then, just in processing pensions and stuff like that, because I was having a crisis like, “I don’t know I want to do with my life.”

Liz Elcoate: Then I moved to working for a Danish company in marketing, which I really enjoyed. I enjoyed the creative side of that as well. I did art and fine art after school, and I hadn’t really done anything with that. I felt that within that role, I was starting to do a little bit more with that.

Liz Elcoate: Then this thing called web design started popping up. My sister said to me, “You really need to get in on this at the start.” I was like, “We’ll give it a go, maybe.” She’s like, “No, I really think it’s going to be big.”

Liz Elcoate: I did a little night course, and of course, the night course was terrible because they tried to teach everything in tables. By that point, we were getting to the HTML and CSS. I then went on the Adobe tutorial forum, or site, or whatever it was back then, and basically learned coding from there, and blindly just got some clients.

Liz Elcoate: It terrifies me now. I think I literally knew nothing. Did some quite hefty websites for people. I think this is quite common… I think a lot of people started off just going, “Yeah, I’ll do your website. Don’t know what I’m doing, but okay.” That’s kind of how I started it.

Liz Elcoate: Then the more I learned, the more I thought, “I don’t know anything at all.” I thought, “I need to get an actual job, an agency.” The first job I went for, a guy called Sean Johnson, who everybody might know now as my cohost of The Freelance Web, he was interviewing me for it. He loves to say, “I hired Liz into her first design job.” Miraculously, I got the job. That was just an amazing experience.

Liz Elcoate: After that, I worked with just a brilliant team of guys, who I’m still really good friends with all of them now, loved every minute. When I say guys, I mean men. There were no women in the kind of design … We worked with the development team, so we had to design, and then we would code up our CSS, HTML, code up the site, and then we’d pass that over to the developers who would build into their CMS.

Liz Elcoate: I worked with some amazing clients then as well. Stayed there for a few years, worked up to senior design executive, I think that was my title, which I never to this day really understood what that meant. It just was pay grades.

Liz Elcoate: Then because of my daughter, who was that time starting secondary school, and she was at a different part, away from where I worked, I was like, “I’m really struggling to do all the mum things, and do a full-time job and stuff.” I was raising her on my own and didn’t really have any kind of support network.

Liz Elcoate: I then was like, “I’m just going to go freelance, sounds easy.” Luckily, I went to my boss and said, “Look John,” who I’d really, really got on well with, “I can’t really do this full time anymore.”

Liz Elcoate: It was a very high-pressure job, because I was managing products from start to finish, and traveling all over the country, and then also doing designs. We had huge, crazy targets to hit every week, like a lot of these agencies, I think, at the time. The pressure was getting crazy. I’m trying to be a mum as well. I said, “Look, I’ve got to go freelance.” He said, “Will you freelance for us?” It was a brilliant start to my freelance career. I’m very lucky.

Liz Elcoate: We did that for a while, ended up parting ways, but by that point, I’d built a client base. Most of my clients then were, it was what we called web design then, which was UX now and UI. I’d done branding within that role at the agency, so it was something I was really confident with.

Liz Elcoate: That was part of the projects. They were full-service projects. They were branding, website, everything, print, design, the whole lot. I felt that I had a lot of strings to my bow, and then I went freelance. That was probably eight years ago, I think. I can’t believe I’ve been putting myself through this for eight years, but that time’s flown. That’s more from UX design to focusing more in on branding, I think.

Drew: Was it a good decision? Have you had a good eight years? Have you ever regretted it?

Liz Elcoate: That’s a really tough … I’ve regretted it a hundred times, at least. I can’t deny that and say … It’s been necessary because of just how my life is structured and stuff, how I’ve had to be there for my daughter. It’s been necessary, but it’s been tough. There’s times when I’ve been so tempted to go back to a full-time role, just to take that financial worry away. It’s tough being worried about money all the time.

Drew: That brings us on to a recent article you wrote for Smashing Magazine called Making Peace with the Feast or Famine of Freelancing. In that you’re talking about the stresses that the irregular nature of work can put on an individual freelancer, particularly when that work isn’t coming, and new inquiries aren’t coming in.

Drew: Was this something that you were aware of right from the start, or was it something that you discovered as time went on?

Liz Elcoate: What’s bizarre is that I think you’re always told to specialize, specialize, specialize. I did specialize. I went into specializing, into branding. As I said before, there’s not a huge amount of work constantly.

Liz Elcoate: If you’re a logo designer, and you’re doing 200 pounds a pop logos, there’s a lot of work out there for you, but I really wanted to do full branding. I guess I made the decision about a year ago. Before, I was doing design, which I guess was UX design, graphic design, print design. There’s always a lot more work coming in. The projects were probably not … Now when the products come in, they’re really good value projects. I think then it was a lot more regular small work.

Liz Elcoate: Everyone seems to dismiss that saying, “No, no, you need the big projects with all the money.” Actually, those small projects as well, do keep you ticking over. I think that I’ve found that I had really dropped the ball at the beginning of this year. I’d had a couple of really big projects, and then I’d had a last-minute project come in in February, and dropped everything to do it.

Liz Elcoate: It was a three-week turnaround, and it was doing some print design for company that I’ve worked with for years and years. They’re absolutely amazing, but they always have insane deadlines. They’re like, “We need to do all of this in three weeks’ time.”

Liz Elcoate: They pay amazingly, so it was one of those like, “Well I’m just going to drop everything.” For those three weeks, I was also house-sitting for my parents because they were in Australia. They have a massive farm, so I was looking after the farm and doing … so my whole days were just mad.

Liz Elcoate: At the end of that time, I also got ill. I went to Copenhagen, and I got quite ill with a bit of quite a serious health scare. For a month, I literally was laid on the sofa. Then at the end of that month, I was like, “I’m getting better,” and I had the results come back, and everything was okay.

Liz Elcoate: I was like, “Oh God, I need to get some work in right this second. Someone give me some work now.” It hasn’t been a problem I’ve had the whole time. I’ve definitely had times when it’s been quiet, and I’ve had a week or two and I’m like, “Ugh,” but this was a long period of time of real dawning on me that things were not great.

Drew: It seems to be one of those things, not just the financial pressure that a freelancer can feel if they haven’t got new inquiries coming in. There seems to be a lot of stress, and anxiety, and things, so that even if things are okay financially, even if you’ve got a bit of a buffer, it seems like there’s a disproportionate amount of stress that it puts on an individual, just with the worry. What did you learn about that in your research for the article?

Liz Elcoate: That was probably my biggest revelation during that time. I think that’s what I really wanted to write the article about, was that I had a buffer luckily, because I had done these three big projects. A bit like everybody, you have loads of work come in and you’re crazy. You invoice it all and you’re like, “Oh, I’m rich.” Then you forget that it has to last you for however long it is until the next project comes in.

Liz Elcoate: I had a buffer, but it was that slow dawning realization that nobody I was contacting wanted to work with me. Immediately, I think, as quite a sensitive person, a creative person, I assumed that was because my work wasn’t up to scratch, and I was really losing my touch, and maybe I was in the wrong industry.

Liz Elcoate: That was really painful, to start to realize that. I thought, “Well, this is all I do. This is all I can do. I’m terrible at what I do for a living.” Unfortunately, I’m not secretly a qualified doctor or lawyer. I can’t just fall back on those things. It takes a long time to become a lawyer, even if I wanted to be one.

Liz Elcoate: It was all that kind of thing. It was a day when I thought, “I think I need to write about this mental health side of this.” Money worry is definitely debilitating, but thinking, “Well, I’m never going to get any more work because everybody’s realized that I’m actually really bad at what I do,” was worse.

Liz Elcoate: I tweeted out about this, and it was just an overwhelming group of tweets that came in just saying, “Oh yeah, I feel exactly the same way,” from really the best designers we have in the industry saying it as well. From the outside, you assume that they’re doing really well, and they never have these problems, but they have times when it’s quiet, and it really affects their mental health as well.

Liz Elcoate: I was like, “I think other people need to realize that other people feel … everyone needs to know that other people feel like this as well, and that it’s perfectly normal to feel like that.”

Drew: In talking to people, did you discover any strategies that people had for coping with that situation?

Liz Elcoate: Yeah. It was great to talk to people about this. I find when I become that worried, I almost become catatonic with worry, whereas I can’t do anything else, because my whole mind is weighed down with this with worry. It would be a case of sitting at my desk all day, sending out emails.

Liz Elcoate: You’re reeking of desperation when you send out these kind of emails. People can tell it a mile off, and you’re not getting anything back. I’d do that for eight solid hours, and then I’d go and watch Netflix or whatever. I’d be like, “Oh my God.”

Liz Elcoate: So many people came up with so many great ideas, like side projects, creative projects, running, walking outside. Walking’s a big part of my life anyway. Up your gyming. If you like fitness, start going to the gym more, because that is only going to be beneficial. It gets you out of it. It gets you out of your head when you’re doing stuff like that.

Liz Elcoate: There’s a wonderful chap … let me just find his name … he got in contact. He lives in New York, Jesse Gardner. He created this wonderful project called Troy Stories, because he lived in Troy, in New York. He basically got desperate in the depths of worry about work and stuff.

Liz Elcoate: He’d started going out onto his surrounding area, and just talking to people, and photographing them, and just finding out their story. It’s just a beautiful project, it really is. His work’s gorgeous. I think it just saved his sanity, going out there, and connecting people, and hearing other people’s story.

Liz Elcoate: Then it’s not all about you then, is it? It’s about other people and their lives as well. There are some really, really good recommendations there, a lot of do some art, cook some food, do something creative.

Liz Elcoate: We’re creative people, generally, who are in this industry. I think when you’re telling yourself that, “Well, I’m rubbish at creativity. I can’t even get paid for it anymore,” to do something else creative is really helpful.

Drew: Underlying messaging in lots of those is just be productive. Find something that you can be doing that will keep you engaged and to keep the juices flowing.

Liz Elcoate: Yeah, and stop you worrying about this huge thing in your life as well. I think I was just spending eight hours a day just applying for jobs, applying for jobs that had nothing to do with what I did for a living, just applying for anything.

Liz Elcoate: It was crazy. I think I went a little bit crazy at the time. Then contacting people, “Have you got any work? Have you got any work?”, just all day. I think if I probably had done that an hour a day, or two hours a day … because you do still have to do that. You still have to look for work … and then spent the other time, I could have done my portfolio.

Liz Elcoate: There’s a million jobs I could have done at the time, that I just couldn’t get my head around. Now after having those conversations, really starting to put some of those into practice, they begin to really help.

Drew: In the article, you’ve put together a toolkit, a feast or famine toolkit, which is kind of like a nine-step program of things you can do that touch some of these. I think it’s a really great read, lots of good ideas in there, things like getting out into nature as you say, running, and walking, and those sorts of things. That’s certainly something I find really helps, even when I’m busy with lots of work.

Liz Elcoate: Absolutely. I think as well, these are all things we should be doing when we’re really busy. I think when you’re very, very busy, it’s very easy to just completely focus on that work and think, “I can’t do anything else. I just have to focus on this work.”

Liz Elcoate: That might drop off suddenly and you’re like, “I’m completely at a loss.” I think if you have these things in your life all the time, then it’s much less terrifying when suddenly, you’re like, “Well, I must start a hobby now, because things have gone quiet, or I must suddenly start running.”

Liz Elcoate: There’s a lot to be said for releasing endorphins through exercise. It can make you feel a hundred thousand times better. My daughter’s at uni now, and she’s under a lot of pressure doing her degree and stuff. I keep saying to her, “Just go to the gym.” She’s like, “I can’t. I’ve got so much reading to do.”

Liz Elcoate: “I went to the gym last night. Mum, I feel really great after going to the gym.” I’m like, “I’m not going to say I told you so.” She said, “I just feel so much happier.” I’m like, “Yeah, I think we’ve all proven that endorphins are good for you.” I really do think there’s some benefit in that.

Drew: I think as well there’s a lot of benefit. You talk about doing side projects, and taking up creative hobbies, and things. Of course, there’s value in not only fueling your creative mind, but also that some of those might turn into work in themselves.

Liz Elcoate: I totally agree, but I think there’s also, don’t start a side project with that in mind, because then it just becomes another chore. I think I’m definitely guilty of that. The minute that I come up with something I quite like to do, I think, “Well, how can I make money out of this?”

Liz Elcoate: I made marmalade the other weekend. I’ve never made marmalade in my life before. I thought, “Maybe this could be a sideline. This marmalade is really good.” I think, “No, you made it because you’re …” It’s one of those particular processes that you go through. Don’t start thinking this could be a business. I’m very bad at that.

Liz Elcoate: I think it’s great to have side projects, but I think the ones that do end up being successful and maybe becoming part of your career aren’t necessarily started with that goal in sight. I think the ones that are started with that goal in sight often don’t work, because they just become a real chore.

Liz Elcoate: Jessica Hische with her Drop Caps, I think she did that for pleasure and fun, and that’s become something she’s so well known for. I think if you set out going, “Well, I’m going to create these amazing things and hopefully it’ll turn into …” I think that sometimes then adds that further pressure.

Liz Elcoate: When I said pursue creative, they can be … I’m a real sad geek, and I really like doing even a puzzle or something, something that really is just mind numbingly, there’s no end, there’s no … well, there is, because you’ve completed the puzzle, but there’s no obvious creative like, “I can show everyone how great my puzzle is.” it’s like making marmalade. It’s just my numbing process, basically.

Drew: I guess there’s a happy medium with those as well for a creative person maybe doing some personal work, just something that where the inspiration takes them and something that they feel like doing. Sharing it on Dribbble might attract some attention that brings in some regular work.

Liz Elcoate: Yeah, absolutely. That really worked for me at the beginning of my career. Wow, this is really taxing the old memory. When I first went freelance I thought, “Okay, I’m going to create an amazing CV.” This is not such a thing these days. I think people are a bit snobby around CVs, but there used to be some really creative, amazing CVs.

Liz Elcoate: I was like, “Oh, I’m going to do that. I’ve got a bit of quiet time. I’m going to do that.” I just went to town and shared it on … I can’t remember, maybe it was Dribbble. That was probably around then. I actually did get quite a bit of work from that, just because it was really creative and I’d gone crazy.

Liz Elcoate: Now I feel like I’m more nervous about sharing those things. I think the more I’ve learned and the more embedded into the industry I’ve got, I’m now less keen to share those things. I think it’s because maybe the tone has changed a little bit on Twitter and things like that. People can really be very critical.

Liz Elcoate: I think back then … she sounds very old … back then it was more of a supportive like, “This is amazing,” kind of thing, rather than, “Well, I think you should do this. I personally wouldn’t have done that.”

Liz Elcoate: I think that has definitely worked for me in the past, going back to your point, just letting loose, and also maybe even do things without thinking. “Well, nobody’s ever going to see this, so let’s just go crazy.” It doesn’t matter. It can be all the worst things you’ve ever been taught not to do, but just go crazy, because they can reap amazing rewards.

Drew: We mentioned briefly about being too busy and when all the work then comes in. The stress is pretty much the same when the work’s piling up?

Liz Elcoate: Yeah. I got really poorly at the beginning of the year because of that. It had been a very quiet Christmas and being very worried, and then it exploded with work. As I said, I had agreed to do this stupid house sitting, which is always incredibly stressful.

Liz Elcoate: I actually made myself, I got quite poorly. It’s exactly the same. It’s just so familiar to a lot of freelancers, I think, this, “I’m too busy for anything else,” kind of thing when it gets to that. Then, “I must do it. I can’t possibly turn it down, or say that I can’t do it for a couple of weeks, because they might go somewhere else.”

Liz Elcoate: There’s this pressure to take it all on if it comes in. Then you could be managing four or five, £5,000 projects at once. That is extremely stressful in itself, because that isn’t something you’d really find in a workplace necessarily. You’d have a support team around you.

Liz Elcoate: I think as a freelancer, there’s also all the admin side of stuff, and all that kind of thing, and life that you have to do outside of work. That can be increasingly stressful, I think. Really, you should be managing your time better. I’m the last person to comment on this.

Liz Elcoate: I’m saying this to myself, “You should be managing your time better.” If clients are coming to you and saying, “We’ve got this deadline,” you’re in charge. You can say to them, “Actually no, if you really want me to do this, I can’t do this for a couple of weeks.”

Liz Elcoate: I think you do have to manage your time well. As a freelancer, you have to be very good at those kinds of things, a lot of things. You can’t just be a great designer. You have to be really good at managing your time and being motivated.

Liz Elcoate: You have to be a good boss to yourself, I think, and not an abusive boss, which I think a lot of us are quite abusive. We are like, “Stay at your desk all day. Have lunch at your desk.” There is no boss in the real world would ever be allowed to treat you like that at all.

Liz Elcoate: I think we have to be really good bosses to ourselves and have time outside of work. It’s so easy for it to be just work and then die in front of the TV in the evening, or X-Box, or whatever, or whatever the kids are playing on these days.

Drew: Liz, freelancing sounds awful.

Liz Elcoate: I know. It does, doesn’t it? Wow, how do I do it?

Drew: Is there anything good about it?

Liz Elcoate: There is so much good about it, like amazing people that I’ve met, amazing community that I’m part of online, having time to go and have really long walks with the dogs, or go and take a day off, or go to London, go and do that. The traveling that I get to do more and more as I get bigger projects is so exciting as well.

Liz Elcoate: Being able to write and get paid to write is a dream of mine. It’s amazing. I wouldn’t necessarily have that opportunity if I worked somewhere else. There’s so many good things about it. Seeing a project from start to finish through and it being successful is so satisfying.

Liz Elcoate: The workshop I mentioned earlier, writing that from scratch and then delivering it, and it being successful was such a high, it really was. Knowing I could engage nine people, 10 people for five hours and keep them interested in what we were doing was really, really exciting for me.

Liz Elcoate: There’s so many good things about it. You’re in charge of your own time. You’re in charge of what you do. It’s worth remembering that, because I think it’s really easy to just … you go freelancing because you want more control or autonomy, and then you just work exactly like you did in a job, exactly the same.

Liz Elcoate: You might as well have stayed in job and had a regular income if you’re going to do that. You need to be flexible and work which way works best for you.

Drew: I guess it’s that that flexibility that enables you to work around whatever family circumstances that-

Liz Elcoate: Yeah, absolutely. I’ve been lucky in that over the years, I’ve had great bosses and stuff, and they’ve always been really understanding about that I was a lone parent. I’ve been a lone parent since she was tiny.

Liz Elcoate: As she got older, weirdly, that became more of a challenge because she needed me to be there more often, particularly those teenage years when I think it’s painful and hard being a teenager, and you need your mum there and your dad there. To have that flexibility, to be able to spend that time with my daughter now is back on that. It’s just so lovely.

Liz Elcoate: The other thing we mustn’t underestimate is, we can go on holiday outside of school holiday times. That’s absolutely great. You can be really flexible with when you go on holiday, what you do with that kind of thing. I found with work, I was always pressured to go during the summer when it was a bit quieter, but it was always hideously expensive because everybody else was on holiday now.

Liz Elcoate: You can take Friday off and you can go to somewhere for the weekend. There’s so much good about it. I would not be doing it if I deep down didn’t prefer it to being employed. I think as well, it’s a long time since I was employed. It’s easy sometimes to look back with rose-tinted spectacles, but there’s a reason I went freelance.

Liz Elcoate: It was highly pressurized, and I really at times couldn’t see a way through the stress and pressure of it. There’s pressure with freelancing, but you can manage it yourself. You’ve not got somebody above telling you what to do.

Drew: Here at Smashing, we’re all about learning. With Smashing Magazine, and the books, and conferences, I think it’s an industry where we’ve got to be learning new stuff all the time. One of the things I like to ask the guests on the podcast is, what have you been learning in your work lately?

Liz Elcoate: Well, I’m really lucky. It’s very pertinent to what we’ve been discussing today, is that I’m learning to run a business. I’m learning to be a businesswoman, and not just a designer now, and doing that through reading and also through working with coaches.

Liz Elcoate: I’ve worked with a couple of coaches. I’ve worked with Paul Boag. I’m also working with Christopher Murphy as well, who’s helping me. It’s great saying I’m a brand designer and I like doing branding, but how do you turn that into a business which regularly pays the bills and regularly has work come in? I’m working through that in the moment, and it’s very exciting. I really love learning that side.

Liz Elcoate: It makes you feel so much more empowered and controlled, to be able to learn proper marketing, and proper networking, and how to target the people I want to work with, and identifying who I want to work with and stuff. It’s very empowering. I’ve been learning that.

Liz Elcoate: I’m also learning, really getting back into UX design and stuff because I love that. I love what I do. I love branding, but I really of enjoy the UX side of stuff as well. I’m brushing up on that and learning a bit more about that again. It’s something that I still had always done, but I’m like, “No, I need to really actively learn more about this now.”

Liz Elcoate: It’s exciting. Lots of learning going on here at the moment.

Drew: You’ve got a couple of podcasts.

Liz Elcoate: Yes, I have, thank you. I have The Elastic Brand, which is a podcast. It began about digital brand design, but I think through the course of doing it, I’ve realized talking to people that it’s brand design, as I said before. That’s really exciting for me.

Liz Elcoate: I get to talk to brilliant designers, not necessarily brand designers, but all kinds of different designers and marketing people, just discussing what all the aspects of a brand, like the storytelling, the brand values, and how your customers feel, and also things like accessibility, and inclusivity, and stuff, which aren’t things that have necessarily really come up in branding particularly.

Liz Elcoate: Then I have another podcast called The Freelance Web that’s been going on for a fair old time now, and we had a big hiatus for a while, but we’re doing again. We never get a chance to actually record, so when we do see each other, we record about eight back to back.

Liz Elcoate: That’s basically just talking about freelancing, which is ironic, looking at the article I wrote from the Smashing Mag about how rubbish I’d been at freelancing. We talk about what to do and what not to do. It’s basically just a conversation about what we’ve done.

Liz Elcoate: That’s with Sean, who is the guy responsible for hiring me into my first digital role, as he likes to tell people.

Drew: We have a lot to thank him for.

Liz Elcoate: So much. Do I? Do I really have a lot to … no, I do. I do, definitely. I’ve got those two.

Drew: Fantastic.

Liz Elcoate: Thank you.

Drew: If you, dear listener, would like to find out more about Liz or hire her to work on your digital brand, you can find her website at, and she’s @liz_e on Twitter. Her excellent Elastic Brand podcast and The Freelance Web are both available to find wherever you listen to your podcasts.

Drew: Liz, thank you for taking the time to talk to us. Do you have any parting words?

Liz Elcoate: Don’t let me put you off freelancing. It really is wonderful and rewarding, and everything that people say it is, as long as you’re proactive and you take time to look after yourself.

(dm, ra, il)
Categories: Design

Smashing Podcast Episode 1 With Andy Clarke: What Is Art Direction?

Tue, 11/05/2019 - 04:30
Smashing Podcast Episode 1 With Andy Clarke: What Is Art Direction? Smashing Podcast Episode 1 With Andy Clarke: What Is Art Direction? Drew McLellan 2019-11-05T14:30:59+02:00 2019-11-05T15:45:22+00:00

The new Smashing Podcast is the perfect way to take a little bit of Smashing along with you on your morning commute, when working out at the gym, or just washing the dishes. We’ll be bringing you a new interview with a Smashing expert every two weeks, directly to your podcast player of choice. You can subscribe in your favorite app to get new episodes as soon as they’re ready, or just listen using the player below.

To get things off with a bang, we’re launching the first two episodes today. Each episode will be accompanied by a post (just like this one) with a full transcription of the interview here on Smashing Magazine.

In this inaugural episode, Drew McLellan talks to designer, author, and speaker Andy Clarke about Art Direction. What is it, and how can it be applied to our web design projects? We dig into the topic and see if we can get to the bottom of things.

Show Notes Transcript

Drew: He’s a well known designer, public speaker and author of numerous influential web design articles and books and has recently released his new book, Art Direction for the Web, with Smashing Magazine. Along with his wife, Sue, he founded and runs a web design studio, Stuff and Nonsense, in North Wales where he consults with companies big and small all around the world. You may know of his passion for gorillas but did you know that as a school child he was Junior National Bassoon Champion for three years in a row. My Smashing friends, it’s Andy Clarke. Andy, how are you today?

Andy Clarke: Eee, I’m smashing, lad.

Drew: So, as I mentioned your new book, Art Direction for the Web, is now available but obviously this isn’t your first book. Hard Boiled Web Design, that I’m sure people will know, and way back in the day, Transcending CSS. When did the idea for this particular book come about?

Andy Clarke: This was an interesting one because, like you say, this is number four in terms of books. Sue had always said that she’d hunt down and kill anybody that asked me to write another one because I am such a bastard when I’m writing books. I’m just not a nice person to be around and so I kind of didn’t ever want to do another, kind of, major book after Hard Boiled. So my original plan was actually to write three little, we called them shots in the whole, kind of Hard Boiled theme. Three kind of little 80 to 100 page, little shots. In the kind of the style of, or the length of, A Book Apart type length. Art Direction was going to be the first one and when I started to get into it which was way back at the beginning of, I think it the beginning of 2018 when I started it.

Andy Clarke: The more and more I kind of got into it, the more I realized that this, there was no way this was going to be a short book. All the things I wanted to talk about were just never going to fit. So I kind of threw the whole three shots idea out of the window and we just concentrated on doing this one. So I suppose the idea for this one came actually quite a few years ago even before a lot of the stuff that I talk about in the book in terms of what we can do with design and what we can do with CSS and all that kind of stuff was even a possibility. But it’s been a long time coming this one, I think it’s the kind of spiritual successor to some of the other stuff that I’ve done in the past. That sounds a bit grandiose, doesn’t it?

Drew: No, not at all. I mean, like many people, I’ve come into this field of building stuff for the web without any real formal background in, well, I’m a developer. I don’t really have a formal background in programming. I’ve just sort of picked it up as I go along and I certainly don’t have a formal background in anything to do with design. I’m not really familiar with the terminology and the concepts and the, a formal training would instill, particularly in design. So for people like me, when we talk about art direction, what exactly is art direction?

Andy Clarke: That’s an almost impossible question to answer because it means so many kind of different things at different levels. But I’m going to give an example. Do you remember back in, I mean we’re talking 15-odd years ago now but do you remember the adverts? In fact, for the show notes I’ll send you some links. But do you remember, there was an ad campaign called “The Cream of Manchester” for Boddingtons Beer. One of the things that they did, there was some really funny TV commercials but one of the things that they did incredibly successfully was a whole series of graphics which went on posters and various other things which were a glass of Boddingtons beer with the incredibly creamy head, which was the most important part of Boddingtons Beer and they shaped the head into all kinds of different things. So it looked like an ice cream and it looked like a quiff and it looked like all kinds of stuff. And what that did was it told the story of what was important about Boddingtons Beer through the medium of design. So it didn’t necessarily just say Boddingtons has a very creamy head. What it did was it showed you that through the visuals but then with the, in combination with the words, you got this very, very clever idea about what Boddingtons Beer was all about. And that, in one level, is art direction.

Andy Clarke: Let me give you another example. I can’t remember which magazine it was, now it might have been Rolling Stone. I can’t remember exactly which magazine cover it was now but a couple of years ago there was a very famous magazine cover and it was a picture of Donald Trump and they’d taken the barcode which normally sits in the bottom left or bottom right hand corner of the cover of the magazine and they’d put it on his top lip and made him look like Hitler. That’s art direction. That’s using design to convey a message to tell a story, to communicate something to an audience but through design.

Andy Clarke: And when we think about applying those things to the web, it is exactly the same kind of purpose but what we’re doing is we’re using all of those aspects of design. We’re using a layout. We’re using typography. We’re using color choices. We’re using all of these kind of design ingredients to do whatever it is that we’re trying to do online. So we might be telling a story of…a story through an editorial magazine or a news story or we might be telling a story about why you should buy my brand of power drill rather than somebody else’s brand of power drill. And it extends even into user experience because we’re really thinking about what is somebody feeling at this point? How do we communicate with them? How do we try and cheer them up, try and cool down. Do we want to be kind of quirky and delightful or do we want to be sort of more serious and conservative. And all of those aspects of evoking an emotional response in somebody is art direction.

Drew: Like accessibility, we often say that that really is the responsibility of everyone in the team but then in practice there tends to be an accessibility expert who really knows their stuff and can sort of help everyone review their work and push things forward. Is it the same with art direction? Is it something that everybody in a team should be looking at? Or is it something you hire in a big bright art director like yourself to come in and tell everyone what they should be doing?

Andy Clarke: No, it is exactly the sort of thing that everybody should be paying attention to. Every decision that we make in terms of design is an opportunity to tell a story. And that can be a big story or it can be a tiny story. And even things, for example, the style and the wording of microcopy can help to tell the story. Now, what we really need is not just everybody kind of paying attention to what that message is but we also need to know what the message is to begin with.

Andy Clarke: And one of the things that I think has been lacking over the last however many years when we’ve been kind of evolving the web as a medium is we’ve kind of moved away from this idea of the web as either a kind of creative medium or as a great medium for storytelling. And that’s the kind of thing if you go to an ad agency, then you’re not going to walk far through the door before you fall over an art director. But that’s not something that you generally find, it’s not a job title that tends to happen at digital agencies. It’s just, you’ll find UX people and project managers and developers and all manner of different, in parentheses, product designers. But the overall thinking about what message are we trying to convey, how do we implement that through design? But then there’s that kind of, what you would think of as creative direction but it is slightly different. Where somebody is basically just checking that everything is on brand, is on message, is part of telling that story.

Drew: As a developer, if I want to start getting involved in the art direction of my projects, where on earth do I start? Is this something that I can learn or do you have to be born this way?

Andy Clarke: I can’t think about the way you were born. You’ve landed on your head. No, it is something that can be taught and it is something which takes practice. So you don’t need to have gone to art school or studied advertising or whatever. I never did. I didn’t even do a graphic design degree back in the ‘80s. I was a failed painter. But it’s the kind of thing where, I think it’s a change of kind of, mindset a little bit. In thinking about, it’s not just about the practical aspects of designing a website but it’s also the thinking about, “Well, what are we trying to do?”

Andy Clarke: So let me give you an example, right. So Smashing Magazine, I did some early conceptual work with them for the redesign that we see right now. And the way that we did that was to basically just host a bunch of workshops where we all got together and we sat around a big table for a week and we did this kind of three or four times where really what we were trying to do was to get to the bottom of what the Smashing message was. And how Smashing wanted to be perceived and that was basically a great big roundtable exercise which was basically designed to just get the Smashing guys, Vitaly and Markus and others, thinking about what the real purpose of Smashing was and how they were going use design to communicate the unique kind of personality and attributes of Smashing.

Andy Clarke: And to help that along, we did a load of, kind of early rough design stuff. And then from what they learnt, they then turned to Dan Mall and said, “Right, we’ve got these words, we’ve got these, call them design principles if you like, that we want to then pull out through the design. We want to be bright and bold. We want the experience turned up to eleven. We want to be quirky” and all these kind of words that had come out of our early design discussions. And then he would then produce designs that sort of fitted with that brief.

Andy Clarke: And the interesting thing about that if we relate this back to your question where you’re saying “Where do I get involved?”, it’s, is, if we were kicking off a project for Notist, for example. The very obvious thing is that it does some things. It hosts your slide decks. It adds your speaker profile or whatever but those are just, they’re the things that it does. But your aspirations for that product are much, much more than just the bunch of practical things that it does. So from a brand and from an art direction point of view, yes, you want to be designing a product which is streamlined and simple to use and reliable and all of the stuff that it, kind of goes with it. But there’s a bigger picture and I would be speaking to you about what that purpose really is. Is it to inspire other speakers to get onstage? Is it to share information more widely? Is it to make talks that happen at remote conferences much, much more visible to people wherever they are in the world. There’s obviously a bigger thing going on in here.

Andy Clarke: And then once we’ve kind of understood what those real, kind of, what our real purpose was, then we can think about how do we convey that message through the design. And that’s where a designer would come in with a creative brief and then we would look at, well, what typography style is going to convey that message? What kind of layout? What kind of color scheme? What kind of graphics are going to really tell that story because you can easily just say the world’s most popular slide deck sharing site as, what’s that nasty one? Not Speaker Deck, the other one. SlideShare. Dreadful, absolutely dreadful. What we would look to do is something like Notist if we consider an art direction point of view is to consider, how do you want people to feel when you’re using the product and how do you want them to feel when they’re making the decision to choose your product over somebody else’s. And that’s essentially what it boils down to.

Drew: So it’s very much about how the brand, in a sense, is embodied in every little detail and every part of the design, both the sort of visual design and the functional design. Would that be accurate to say?

Andy Clarke: Yeah. Yeah, absolutely, and that should be the case with anything that we’re making. It’s why I get so disappointed when I see stuff which is not a gajillion miles away from framework default in terms of layout or button styles or type hierarchy or whatever it happens to be, all of these kind of design things. Because, to me that’s like completely missing the point of the design. Yeah, it might be a functional thing to use but does that make it nice?

Drew: So obviously modern websites are mostly spat out of a CMS into identical templates. So if kind of one of the jobs of art direction is to invoke this sort of emotional response to something on a page, can that be done through spitting out content into templates or can it be done by machine?

Andy Clarke: Well, if I had the solution to that problem, I’d be a very rich man because it is actually the problem that a massive amount of the web is struggling with. Whether it would be news outlets or magazine outlets or editorial or whatever. And it’s a question which comes up again and again and again. And actually the people that have really solved this problem best of all that I took to my knowledge it ProPublica who I talk quite a lot about in the book. And our old friend Rob Weychert basically designed the CMS implementation for ProPublica. And the way that they did it was that they said, “Right, okay, these are our foundations style, this is what the ProPublica website looks like and an article on that website looks like if I do nothing. This is what it is.” But obviously they want to be able to customize that in all kind of different ways whether it would be type or layout or color theme or anything else. What they did was very simply they just had a field in the CMS that they could inject custom CSS. And because they understood the cascade and they understood how CSS builds they would only then be able to overwrite certain things.

Andy Clarke: Now, not everybody’s going to want to go to the extent of custom designing articles in the way that ProPublica do. And they don’t art direct or over design everything. It is only these really kind of special pieces that they tend to do a really great art direction job on. But there are ways in which we can do this. One of the great, we always talk about separation of, or we used to talk about, it used to be the thing where we would separate content and structure and style and behavior. Now it seems like everybody piles everything into JavaScript but moving swiftly on. One of the things that you can do, is you can separate out the CSS logic. And as long as you don’t bake in the style of the page into the HTML, as long as you keep things flexible, you can then do an enormous amount, particularly when we’ve got things like CSS grid, flex box, which are kind of, almost like content independent in a way, and CSS variables.

Andy Clarke: So I’m working on site with a French football magazine which will hopefully be finished by the time this podcast goes out and that’s a question that we’re trying to solve right now. So what I’ve done over the last couple of weeks is I’ve designed probably about half a dozen different layout templates. Now, some pages are fixed. They’re never going to change, they’re never going to be wildly different. If you think about something like a league table or a list of results from a football Saturday then you’re not going to do an enormous amount with it. But when it comes to things like player profiles and team profiles and some of the more, kind of, involved content, what I’ve done is I’ve designed about half a dozen different layout combinations. All based on exactly the same CSS. And what I’m doing is I’m then extracting out certain things that, for want of a better word I’m calling themes. Just in terms of right, in this design, Design A, and I give them all names. I give, I’ve given the theme, I’ve named them after French football players. So if you want to, if you look at the Cantona design or Cantona theme, what do the headlines look like? What do the block quotes look like? What do the table headers look like? What do the buttons look like? There’s a specific style that goes into that theme which is independent of the layouts.

Andy Clarke: And the other thing which is independent of that theme is the six different color schemes that I’ve come up with. So basically by the end of the project, you’ll have a color layer, a theme layer and a layout layer that they are able then to kind of pick and choose. And that can be automated, it can be turned into toggle switches in the CMS or whatever it might happen to be. So there are ways of doing that.

Andy Clarke: Now that’s not a particularly kind of appropriate thing for, in terms of pure art direction but the same mechanics can then be used if we want to be saying right, “Well, we do want to customize this so let’s introduce these new fields.”

Drew: One of the examples in the book, quite early on of a, sort of art directed site is the UK government’s site, which is excellent as a user of it. It’s a site I really enjoy using it but it’s not one that I would immediately think of as being art directed, in inverted commas. It’s not very visually rich. It’s quite sparse and not sparse in a minimalist way but sparse in a utilitarian way. Art direction doesn’t need to be flashy, I’m taking from that?

Andy Clarke: Well, I have spent years joking about and I’ve always thought of as being the website that design forgot. I’ve often said, not known for its creative flair. And it was interesting, when I was doing a series of podcast interviews for the book, I was talking to Mark Porter, who used to be creative director at the Guardian. You can’t read a book about editorial design without Mark cropping up at some point. In fact, he’d be a great person for you to speak to on this podcast at some point to get a different perspective. And I was saying to Mark in our conversation, “Look, I can remember great art directed ad campaigns on TV, in magazines. We’ve talked about art direction in newspapers and print publications, etcetera, give me an example of what you think is great art direction on the web.” And I was absolutely stunned when Mark said, “”

Andy Clarke: And it took a while to sink in but actually he was absolutely right because if art direction is about making people feel in a certain way then does its job incredibly well. It doesn’t need to be flashy. It doesn’t need to be overly designed. It doesn’t need to push boundaries or do any of these things that you might associate with newfangled CSS grid webby stuff because it does what it does and it’s, the design is absolutely appropriate to, not only to the audience and what they want to do but also how want people to feel when they’ve left the site. When you’ve gone on there and paid your car tax or looked up when your bin collection’s going to be or whether it’s safe to travel to Cameroon or…I leave that site reassured that I’ve been given the information that I was looking for in a thorough and professional way. I don’t think to myself, “Oh, is that site trustworthy?” And not just because its but because the whole experience has just been designed to leave no unanswered questions in my brain.

Drew: Yes, it’s so, sort of simple. It gives you real confidence in the information you’ve found is correct or the process that you followed, there’s a very clear way through it so you feel like, “Yes, I’ve completed that successfully because it was unambiguous.”

Andy Clarke: Now, would I design certain things differently? You can bet your bottom dollar I would but would I want to think about improving typography? Yes. Would I want to get more granular in terms of typographic design so that we can improve the way that numerals look or dates look or tables of data look or whatever? Yes, absolutely there’s some things that I would look at there and say, “I want to improve the design of that aspect of” But in terms of the art direction, no, everything that they, that you see whether it’s intention or not in terms of, I don’t know whether there is an art director at, but everything that you see just contributes to how people feel at the end of the experience and that’s good art direction.

Drew: The book itself is really beautiful. I’d seen the ebook version of it early on which is absolutely terrific and I recommend that. But then I had the pleasure of picking up an actual printed version and I really recommend the printed version even more. It’s, every sort of spread is as you’d expect, sort of custom designed and it’s just jampacked with loads of inspirational examples. And it’s so heavily illustrated, I mean there’s hardly a double page spread that’s all text. It’s all illustrated with stuff. It’s really great. To be honest, it’s not the sort of book, not knowing anything about art direction before our conversation, and before looking at, actually looking at the book. It’s something I wouldn’t have picked up thinking it was for me but once I started looking through it, I thought, “Yeah, this is really good.” Obviously, you’ve designed it, you’ve designed every spread by hand. What was that process like?

Andy Clarke: It was a lot of work. I mean, first of all, I just want to say an enormous thank you to my son, Alex, who actually typeset that entire book from start to finish. What we wanted to do when we set out to produce the book was to show off some inspiring stuff but we also wanted it to be incredibly relevant to people at various different stages or different areas or whatever. And Sue would be quite, sort of brutal with me and say, “Don’t forget to explain it this way. If somebody’s using Squarespace or Shopify or Bootstrap Grid or whatever, then you need to talk to those people as well.” So what I did was, I actually spent about three months designing a whole ton of different examples. And me being me, I had to kind of, everything had to be perfect. There had to be a theme so I kind of came up with this hard boiled based London gangster theme for an app and a website that kind of goes with it. And then everything kind of just spread on from there. What was interesting in terms of the actual design of all those examples was what you learn how to design in one part of the book you then learn how to build in another part of the book. So there is this kind of balance to it.

Andy Clarke: But then, so basically what would happen is, was that I came up with about half a dozen different layout scamps for the main body of the book. I was much, much more detailed on the, sort of the examples I didn’t design, some of the other examples from elsewhere on the web. But the general body of the book, I just did half a dozen, kind of just very simple box layout sketches. Alex would then interpret that and chapter by chapter we would then go through it. So literally every single page has been tweaked. And I haven’t done, I’ve never done a book that’s got, had that much attention to detail.

Drew: Yeah, it really shows and the end result is fantastic and I’ve been learning a lot from it. So something I always like to ask people. I’ve been learning about art direction, what have you been learning about lately? Is there anything in particular in your work and your projects that you’ve been learning and swatting up on?

Andy Clarke: Yeah. I’ve been really trying to get to grips with more advanced grid stuff. That’s something which I’ve been really trying to sort of push the boundaries of. And along with this kind of, because I’ve been experimenting with, “Here’s a great, here’s a quirky layout. How would we build that?” And along the way comes things like SVGs and making SVGs responsive and I actually learnt today that you can’t use the picture element with inline SVG. You have to use an IMG element if you want to swap one picture for another or one source for another in HTML. So my main, I’ve actually been going back to really just learn a hell of a lot more about code. I think that quite, you go through phases where there’s a huge amount to learn or it seems that way and there’s something new that you want to get to grips with. And then things kind of plateau out and you churn through the same stuff or you use the same patterns or the same kind of methodology for awhile and then there’s another spike. And I’m kind of in one of those spikes at the moment.

Drew: Obviously the book is available now. You’ve also been writing a series of articles for Smashing Magazine around some of the same sort of ideas, picking out some bits and bobs which we’ll link to in the show notes. But you’re also doing a webinar series, is that right?

Andy Clarke: Yeah, well, the articles in the webinar is all the same stuff so I called it Inspired Design Decisions. And it came about because I was actually in Magma Book Shop, which is a brilliant magazine book shop in London, before Christmas. I was with our friend, Al Power, and we were kind of thumbing through magazines and I was geeking out and going, “Oh, look at this beautiful quote. That layout looks amazing. Coo, I love the way that they’ve tied this image with the color of the text and blah, blah, blah.” And Al said, “Well, I’ve never really thought a bit like that. I’ve never really thought about lessons that we can learn from editorial design or magazine design or other things. And you just talk about it in ways that just make sense. You ought to write about this stuff.” So I don’t want to write another book at the moment because well, Sue would hunt down and kill anybody that asked me to. So the idea came about was, well, why not do a series of articles over the course of the year where I would touch on a particular topic and a particular piece of inspiration.

Andy Clarke: There’s three gone out now, so far. There’ll be four, maybe five by the time this podcast goes out. Each one is the webinar content with Q&A. Everybody that is a Smashing member also gets access to a really, really nicely designed PDF version of all of the articles and all the code that goes with it. And then what we do a month later is we’ll put that article out for free on the public Smashing Magazine website. And what we’ll do sometime next May, is we’ll collect all of those twelve articles together and we’ll re-edit them and get the continuity right and that’ll be another book that comes out, probably next April, May time.

Drew: That sounds great.

Andy Clarke: It’s a lot of fun.

Drew: If you, dear listener, would like to hear more from Andy, you can follow him on Twitter where he is @Malarkey and find examples of his work and hire him via his website, Art Direction for the Web is available now through Smashing at and I commend it to you. Andy, do you have any parting words?

Andy Clarke: (Beep) to Brexit.

(dm, ra, il)
Categories: Design

Build A Seamless Spreadsheet Import Experience With The Help Of

Tue, 11/05/2019 - 02:00
Build A Seamless Spreadsheet Import Experience With The Help Of Build A Seamless Spreadsheet Import Experience With The Help Of Suzanne Scacca 2019-11-05T12:00:59+02:00 2019-11-05T12:35:15+00:00

(This is a sponsored post.) If you’ve ever attempted to build a CSV importer before, you know how frustrating it is to dedicate valuable engineering time to this feature, only to watch your customers struggle with it.

In some cases, developers try to improve this experience by providing users with FAQs and tutorials that show them how to correctly use their importer. However, this merely shifts the burden from the product onto the user. The last thing users want is to sift through lengthy documentation or video tutorials to upload a simple spreadsheet.

Should it be your users’ job to figure out why your importer isn’t working correctly?

If you want to improve the experience users have with your product or service, you have to start with optimizing the experience of importing the data itself. Users rely on your product to extract value from it. Asking them to use a spreadsheet template, or to match their fields before they've even uploaded a file to your app is detrimental to their product experience and your team's resources.

Investing developer time to fix an existing data importer, or worse, building a CSV importer from scratch is a huge strain on resources. Let's look at Flatfile, which enables developers to integrate a robust CSV importer experience in as little as one day.

Common Problems With Typical CSV Import Experiences

Data import is often one of the first interactions users have with an app. Unfortunately, there are too many ways that this import feature can cause frustration.

For your users, an inefficient importer experience will cause them to wonder whether the product itself is worth using.

If the app can’t import my data easily, what the heck is going to happen once my data is finally uploaded? Do you really want you and your users to battle with these kinds of errors? (Source: Flatfile) (Large preview)

An inefficient data importer strains internal resources. Not only have you invested significant time trying to build what is essentially a second product for your app, now you’re spending time dealing with:

  • Emails and support tickets from frustrated users who can’t upload their data into your system.
  • Broken data, which your team has to manually clean before it’s usable in your database.
  • A never-ending string of inconsistent file uploads, due to lack of data normalization.

This is generally not a good position to be in, as users expect a seamless product experience from start to finish.

Worse, all that effort you spent building your importer could have been dedicated to building core product features your users need.

One of Flatfile’s clients spoke to them about the pain of building and maintaining a proprietary data importer for their real estate product. The client’s engineers spent about eight to ten hours per user, cleaning up and formatting incoming data. Sometimes these users would churn, wasting valuable development time.

There is no point in building a custom feature that's supposed to automate and streamline the import experience. Ultimately, this sets you up for maintenance headaches down the road with features that won’t scale with your product.

Wouldn’t it be better if there was an out-the-box CSV importer that could do this on its own?

Flatfile is what you need.

An illustration of some of the more frustrating data import experiences users have and how Flatfile fixes them. (Source: Flatfile) (Large preview)

Let’s look at some ways that importing data has gone awry and how it can be fixed when you let Flatfile do the heavy lifting.

Issue #1: Unclear Guidance

In some cases, users struggle with your data importer because they have no idea what to do with it. Here are some questions they may ask during a CSV import:

  • Does it accept XLS, XLSX, or XML file formats?
  • What do I do if my file is 97MB in size?
  • What if my file has special characters?
  • What happens if my columns don’t match?
  • How do I fix my data? Do I need to save a duplicate CSV and upload that file instead?
  • Can I update any incorrect data during import?
  • Do I need to download a template?

Unfortunately, unless your users are tech-savvy and spend a lot of time exporting and importing spreadsheets, they’re not going to think about these things until they're ready to provide their data.

It shouldn’t be up to your users to read through or watch a 15-minute tutorial on how to import spreadsheets into your product. Developers aren't spared either. Although engineers understand the complexities of importing data into an advanced system (like Microsoft Azure), there is still an exhaustive amount of content they need to understand before the first import even happens.

A highly technical product like Microsoft Azure attempts to reasonably present developer users with extensive documentation for importing data. (Source: Microsoft Azure) (Large preview)

Your data import experience should make it simple to upload CSV data without requiring users to take a mini course on it. The same goes for your understanding of how to build it.

Here is an example of a simplified CSV import solution for a CRM from Flatfile (you can ignore the code on the left-hand side for now):

A demonstration of how Flatfile helps developers simplify and clarify CSV import for users. (Source: Flatfile) (Large preview)

Notice how the preview of the importer shows a welcoming, yet basic setup. Your users would instantly know to:

  • Upload their data as a CSV or XLS.
  • Match their spreadsheet columns in the next step, if needed.
  • Click “Continue” to begin the CSV upload.

Part of this is because the standardized UI presents no obstacles while the synchronous guidance prepares users for what’s to come. This way, users won’t worry right off the bat if their data will be imported incorrectly.

Issue #2: Maxed-out Browser Memory Limits

Let's assume that your users have successfully exported their data from another system or compiled it into a CSV file on their own. Then, they initiate an upload using your product’s data importer.

However, after watching the upload progress for what feels like an eternity, they receive the dreaded “Upload Failed” message. This isn’t all that uncommon with traditional or self-made data importers.

It’s often why online forums and website support centers contain question-and-answer like this one on the Go1 website:

Go1’s support center answers the question “Why Has My CSV Upload Failed?”. (Source: Go1) (Large preview)

Or this one on the Nimble website:

Nimble’s support center answers the question 'Why am I getting an error message when uploading my CSV file?'. (Source: Nimble) (Large preview)

Or this one from Nurture’s knowledgebase:

Nurture’s Help & FAQs answers the question 'Why is my CSV file failing to load?'. (Source: Nurture) (Large preview)

Ultimately, it falls to your users to:

  • Accept that CSVs have a tendency to fail.
  • Debug what causes a failed CSV upload.
  • Figure out how to trim back their file size, rearrange their file, or download and use the product’s template in order to complete an upload.

Why should it be up to your users to figure out why your data importer failed? Shouldn’t you be the one to sort out the disconnect? Or, better yet, to build an importer that works without issue?

With Flatfile, you and your users won’t have to worry about things like file sizes or formats causing problems during import. For example, Flatfile helps you manage imported data via the browser or through a server-side process, enabling you to upload large CSV files without bothering your users. Another solution provided by Flatfile comes in the form of file-splitting.

A Flatfile demo that shows how you can reliably break up and import data from multiple files. (Source: Flatfile) (Large preview)

Flatfile allows users to import CSV data from multiple files intuitively, without dropping data or doing manual splitting.

In this demo, users are allowed to upload CSV files containing three different sets of data. Not only will this help make their files more manageable, but it’ll make it much easier for your product to ingest and organize the data on your backend.

Issue #3: Vague Errors

It’s not just vague upload instructions or stalled imports that are going to give your users a headache.

When the error message is vague, what is the user supposed to do with that? Without a specific explanation of the problem, your users are going to be stuck having to work through every possible fix until they find one that works (if any).

Take this reported issue with Jira:

Jira knowledgebase tries to help users that see the vague error message that reads “Unexpected failure occurred.” (Source: Jira) (Large preview)

The full error message reads:

Unexpected failure occurred. Importer will stop immediately. Data may be in an unstable state.

That’s not helpful. So, not only does the developer see a message calling their data “unstable”, but now they have to work through the issue from the scant details provided on this help page. The answer actually includes this as an explanation, which we can assume is only going to add to the frustration:

This happens because the JIRA Importers Plugin tries to validate if the issues are valid for importing, and when the validation fails the error above is thrown.

Essentially, the plugin is incapable of recognizing “Required” fields outside of the ones it deems as required. But rather than transmit that message in the importer, users have to figure that out from this resource.

Not only is there no explanation for why the CSV upload failed, but it then suggests that the data importer might’ve just goofed up (which won’t reflect well on your product experience). Chances are the importer isn’t going to accept the same file twice, so why bother suggesting a retry?

It’s not your users’ job to think here. CSV importers should be designed — error messages and all — to make this a quick and painless experience for your users.

Issue #4: Mapping Is Inefficient

The next source of frustration often appears when poor column-matching functionality is in place.

As an example, let’s say that a MailChimp user wants to load as many contact details into the email marketing software as they want. After all, it might be useful to have their business title or phone number on hand for future list segmentation.

This is how MailChimp’s CSV field-mapping system displays uploaded results. (Source: MailChimp) (Large preview)

The app doesn’t recognize three of the four columns in our file. In order to keep the unmatched column data, the user has to go through each field and manually assign a matching label that MailChimp accepts.

In this case, the only column that can be edited and matched is “Customer Name”. In this example, the user is going to lose the rest of their data.

We know what you’re thinking: “Why not just provide a pre-built spreadsheet template?” However, this is hardly a solution to the problem and will only create more work and frustration for your users.

The problem here lies within the product experience, not the user.

Historically, this has been a difficult and expensive project to take on, but that’s where Flatfile’s machine-learning, column-matching solution comes in handy.

ClickUp, powered by Flatfile, has leveraged this for its productivity web app.

The main data import modal for users that want to import tasks and projects into ClickUp. (Source: ClickUp) (Large preview)

For starters, this import modal is really well designed. Instructions are clearly provided as to what the user can upload. In addition, the manual option lets users preview what sort of data can be imported into the productivity software. This helps users preserve as much data as possible, rather than realize too late that the data importer didn’t recognize their columns and dropped the data out without any notice.

Flatfile streamlines column-matching as well:

Flatfile asks users to identify column names for accurate mapping. (Source: ClickUp) (Large preview)

This step asks users to indicate where their column names live. This way, the importer can more effectively match them with its own or add labels if they’re missing.

Next, users get a chance to confirm or reject Flatfile’s column matching suggestions:

Flatfile uses a smart column-matching system to automatically map users’ imported data. (Source: ClickUp) (Large preview)

On the left, they’ll find the columns and labels they imported. The white tab to the right provides them with automated column matching for ClickUp. So, “Task” will become “Task name”, “Assignee” will become “Task assignee(s)”, “Status” remains as is and so on.

If one of the labels in the CSV doesn’t have any match at all, the importer calls attention to it like this:

Flatfile calls attention to labels or values that don’t have an exact match in a product. (Source: ClickUp) (Large preview)

In this example, the Priority response of “High” was detected. But “Medium” was not. However, there’s no need for the user to guess what the correct replacement should be. The importer provides relevant options like “Urgent”, “Normal” and “Low” to replace it with.

Once all spreadsheet labels have been resolved, the user can easily “Confirm Mapping” or discard the column altogether if it’s proven unnecessary.

Users get a chance to confirm CSV labels and clean up the spreadsheet results before importing their data. (Source: ClickUp) (Large preview)

Finally, users get a chance to review any errors detected with their data:

Errors detected in ClickUp’s data import appear in red. (Source: ClickUp) (Large preview)

Flatfile highlights required fields that are empty, contain an obvious error or divert from the data model ClickUp specified in their back-end.

The user can rely on Flatfile’s detection system to find those import errors. The “Only show rows with problems” toggle in the left-hand corner makes it even easier to spot.

This keeps users from having to:

  • Review the original CSV file and fix errors before re-importing again.
  • Import the data and do the cleanup afterwards in the app.

How do you set up this system of column-mapping and error detection? Flatfile does most of the work for you.

There’s no need to build your data importer from-scratch with Flatfile. (Source: Flatfile)(Large preview)

Flatfile is configured via a JSON code snippet. Any fields or labels you specify in this code will be reflected in the importer. This allows for column-matching and even complex validation for things like normalizing phone numbers or date formats:

This Flatfile demo provides the pre-written JSON code on the left and a sample of the importer output on the right. (Source: Flatfile) (Large preview)

Flatfile has already been coded for you. You just need to align your data model with what you expect your users to import into your product.

Here’s a JSON snippet you might use to customize the Flatfile importer for a basic contact list:

An example from Flatfile on how to code in your own keys and labels for a basic contact list import. (Source: Flatfile) (Large preview)

You can then use validators to set strict rules for what can appear in the corresponding fields:

An example from Flatfile on how to code in complex validators including regex for CSV imports. (Source: Flatfile) (Large preview)

Bottom line:

It’s not easy building a data importer yourself. Integrating Flatfile allows you to focus on other core features of your product’s experience, knowing that the CSV import experience is taken care of.

Wrapping Up

One of the reasons we build SaaS products is so users can effectively manage their businesses without the costly overhead of outsourcing to a third party or the costly practice of trying to implement everything themselves.

However, just because you know how to build a feature that addresses those needs, doesn’t mean you should, or want to, build an importer.

Of all the things that can stand in the way of you getting and retaining users in your app, don’t let something like importing data be the reason for customer frustration or churn. You can see how easy it is for users to become soured on the slightest inconvenience with common CSV import errors. Take advantage of a tool like Flatfile whose sole focus is designing faster and more seamless CSV import experiences for your users, teams and products.

(ms, ra, yk, il)
Categories: Design

Creating Online Environments That Work Well For Older Users

Mon, 11/04/2019 - 03:00
Creating Online Environments That Work Well For Older Users Creating Online Environments That Work Well For Older Users Barry Rueger 2019-11-04T13:00:59+02:00 2019-11-04T14:36:16+00:00

With the single exception of my 94-year-old mother, I don’t know a single person over the age of 65 who doesn’t have a smartphone, computer, or tablet, and usually all three.

I’m well past sixty, and have worked my way through punch cards, a C-64, many versions of Windows, Apple and Linux. I know at least a few people over seventy who have a programming background or who have spent a lot of time doing graphic design and computer music composition on various machines.

That’s why I’m always amazed to read comments like these:

“Amazon Echo has been particularly popular with the older generations, as it allows them to interact with technology and the Internet in a natural, personal way, rather than via a computer.”

We are the generation that invented and grew up with personal computers. It’s absurd to suggest that we are less capable of using technology. In other words, you can’t complain about old people not understanding tech, and then also complain that they’ve taken over Facebook and Twitter.

Even though we’re as tech-savvy as anyone else, older users have some specific needs that web designers and programmers should consider. None of them are particularly difficult to accommodate, but they can be critical for our use and enjoyment of the Internet. As a bonus, you’ll be designing environments that will also work for you when you get older. “Older” meaning “past forty”.

Text Is Preferred, As Is Grammar And Spelling

I’ve been online since the 300 baud BBS days in the mid-80s, but like most people over fifty, I spent the first half of my life relying on books, newspapers, and magazines for almost all my information needs. I prefer text over video because I can absorb and retain information faster by reading than by watching YouTube. Unless it’s something hands-on like a car repair, I’ll ignore any search result that points to a video.

I routinely skip past pages that are mostly big pictures with short captions. If you’re showcasing professional photography or artwork that’s fine, but for most things, I’m looking for well-written copy with images to complement or expand on the text. A well-chosen image can certainly improve a web page, but it’s the written word that draws me in.

Because I grew up reading and writing text, I also care a lot about how well it’s written. Just because you’ve created thousands of tweets or forum posts does not mean that you’re a professional caliber writer. I’ve been writing for decades and know that I still have some skills that could be improved. If you don’t have writing chops you need to hire a real writer to create your copy, and hopefully a real editor to fix what the writer misses. If your page hasn’t been spellchecked and proofread, you’ll lose me pretty fast.

A typical older computer user (Source: Wikimedia Štěpán Pech) (Large preview) Black And White Please

Any Internet user over the age of sixty will complain that many pages are impossible to read — as are food packages and the tiny printed ‘Quick Start Guides’ that have replaced user manuals.

It’s not because we don’t appreciate current design choices, or because we’re behind the technological curve. It’s because so many web designers have decided that pale gray type on an equally pale field is something that looks good. At age twenty, that may seem like a valid choice, but as the rest of us age, our eyesight changes for the worse. After age forty, eyesight deteriorates enough that we need black text on a white page.

The American Optometric Association describes this deterioration:

“Beginning in the early to mid-40s, many adults may start to have problems seeing clearly at close distances, especially when reading and working on the computer. This is among the most common problems adults develop between ages 41 to 60. This normal change in the eye’s focusing ability, called presbyopia, will continue to progress over time.”

As well as presbyopia, most people will eventually deal with one or more of cataracts, macular degeneration, a deterioration of color vision, or a loss of peripheral vision. On top of that, we’re dealing with the inevitable and unstoppable loss of synapses, with the nerve cells that carry information to the brain disappearing one by one.

None of this is in any way unusual — it’s just part of the aging process and sooner or later affects everyone. Although cataracts can be repaired with new lenses, and many of us have reading glasses, most of these conditions are irreversible.

Recommended reading: Using Low Vision As My Tool To Help Me Teach WordPress

Unfortunately, for those of us with declining eyesight, there are a lot of web designers that seem unaware of any of this. A quick Google search will turn up years of debate about black versus grey text, most of which boils down to young guys saying “I can read this pale text just fine,” and old-timers replying, “But I can’t!”

This is not about who’s right or wrong; it’s about creating web content that everyone can use. Just accept that if you want 50+ aged visitors, you need a contrast ratio of at least 4.5 to 1 between text and a text’s background. (This is defined in the Web Content Accessibility Guidelines 2.0 (WCAG).) A good guideline is that on a white background text should be #959595 or darker for larger typefaces, and #767676 for smaller print. If you really need to have a gray background, the text needs to be darker than this.

Black on white is still preferred. (Large preview)

As well as offering us high contrast black-and-white type, you need to think carefully about the size of the typefaces you use. Fine print may be acceptable on a car rental contract that no-one looks at, but it will send website visitors back to Google to find a source that they can actually read.

What size is good? A 2011 article at this very site by writer D. Bnonn Tennant suggests 16 pixels, and he explains in detail why this is the accepted minimum. In a nutshell: because that’s the size that web browsers are designed to display and it’s a size that most people can read easily on their device. Some designers suggest that you set your base font size to 100%, and let the browser present a font size that most users will be able to easily read on that device. On a desktop monitor, 100% defaults to — you guessed it — 16 pixels.

At this point, someone will usually say that users can just zoom. Tennant counters this easily:

The users who will most need to adjust their settings usually don’t know how. And the users who do... well, they’ll probably just take the easier path by hitting the “Back” button. ...Our personal tastes are not more important than best practices in usability.

Note: All of the above are general recommendations for text size. If you’re really serious about the science of vision and screens, you need to read Robert Mohns’ “What’s the best font size for the web? Well, it depends.”.)

Have Reasonable Tech Expectations

Before computers, I spent many weekends constantly upgrading and tweaking my 1969 Dodge Charger to get maximum performance, and when I started using and building PCs that DIY zeal carried over. Somewhere around the turn of the century, I stopped doing that. One reason was that it had become boring, but more importantly, it just wasn’t needed anymore. Unless your target audiences are gamers or niche groups like animators, it’s likely that computer upgrades happen every few years — not every few months.

I’m not alone in stretching the lifespan of my hardware, and older users are more likely to keep their computers until they are truly at the end of life. Although the common guideline is to replace computers every four years, according to Statista five to six years is the norm.

Depending on your target audience, you might also consider the number of people who hold on to systems much longer than that. I don’t need the biggest, fastest, and newest machine on the block, and my wife held on to her Windows XP machine until three years ago because “every time that you do an upgrade it breaks something.” When her motherboard gave up the ghost, she moved to an HP Envy Laptop that has mostly proved her right — it’s been one long battle with Windows 10.

Dell E6400. Still my daily driver. (Large preview)

I recently abandoned Gmail. For the last year or so, that single Chrome tab would invariably consume every scrap of my 4 gigs of RAM and grind my trusty Dell laptop to a halt. Changing Gmail for Thunderbird means that I don’t need to upgrade the memory (or anything else) and I’ll squeeze another couple of years out of this machine. For my uses (which are primarily web browsing and writing), I am perfectly productive using the applications that installed with Linux, and I honestly can’t see that changing. If your website demands too many resources I’ll go somewhere else, and this is true of a lot of older users that are happy with their existing, older tech.

My advice is to test on older, slower, less capable machines to see how your work looks and performs. If the site moves slower than molasses, you might look for ways to improve things.

Understand Our Expectations

Mine is the generation that invented personal computing and the Internet. Our experience has been that every year the Internet will get easier, more reliable, and more enjoyable. Sadly, that hasn’t been the case for a while now.

I can remember being one of the first people in my town with high-speed DSL Internet, and being amazed that web pages now appeared in a flash instead of taking seconds to load on a dial-up connection. My expectation is still that a website should load completely in a couple of seconds, but these days far too many sites take twenty, thirty, or sixty seconds to load all of the ads, pop-ups, clickbait, and gimmicks. That kind of lagging performance is enough to drive me away. I don’t think that I should have to wait for a website to load and if you can’t find a way around that, you’ve lost me.

With a cable connection that promises 150 megabytes per second download speeds, I feel that every webpage should load completely in a second or two. If some part of your page still hasn’t arrived after a few seconds, I’ll leave. When the text that I’m reading suddenly disappears two inches down the page to accommodate a slow-loading ad, my first instinct is to click the Back button and look elsewhere.

Older users understand that time is valuable. We’re conscious that we have only a finite number of years, days, and hours left, and not wasting our time shows that we’re respected. If your site takes forever to load or is “down for maintenance” more than once a year, or if it expects us to jump through multiple log-in hoops every time that we visit, we’ll go somewhere else that’s faster and easier.

If It Ain’t Broke, Don’t Fix It

Part of the reason why has taken over the retail world is because over the last decade the user experience has remained consistent and predictable. Despite adding Prime, and video streaming, and the whole AWS empire, the process of searching for a product, choosing it, and buying it really hasn’t changed. For many of us, that’s what keeps us coming back even if we might question some of Amazon’s corporate behavior. We know the site, and we know that we can do our shopping quickly and painlessly.

If your site works fine for us today, resist the urge to reinvent it. The first concern of every web designer should be how well a site functions, not whether it uses the newest and coolest technology. Before making changes, think long and hard about whether you’re breaking something that works just fine.

If you take the time to really consider these suggestions, you’ll likely realize that they don’t just benefit older people. Anything that makes your site easier to read, easier to use, and which gives visitors a consistent experience is a positive thing. Improvements to accommodate older, slower equipment will also make your site faster for people using bleeding-edge tech. And as a bonus, a lot of these ideas also help you to build a site that works well for people with legally defined disabilities. Design that acknowledges accessibility makes a website that works better for everyone.

Extra Resources

For really useful guidance in this area, I’ll suggest that you stay away from forums and discussion boards. Instead, check out some of the longer, and more evidence-based articles that look at these questions in more detail.

(dm, yk, il)
Categories: Design

Things We Can’t (Yet) Do In CSS

Fri, 11/01/2019 - 08:00
Things We Can’t (Yet) Do In CSS Things We Can’t (Yet) Do In CSS Rachel Andrew 2019-11-01T17:00:00+02:00 2019-11-01T19:05:46+00:00

Building “magazine-style layouts” by using CSS Grid has become something of a pastime of CSS fans, keen to play with the capabilities of new Grid Layout. It’s something I’ve done myself as well as with people who’ve attended my workshops. However, I always have to pick the layouts carefully because, in truth, there are a number of very common print layout patterns that we can’t currently do on the web.

In a lot of cases, however, we can do these things with CSS —just not on the web. If you have read some of my previous articles, such as “Designing For Print With CSS”, you’ll be aware that CSS is also used for print formatting via user agents designed for outputting to PDF. These user agents have often implemented specifications or extensions to specifications that have never been implemented in continuous media, such as the scrolling and non-paged content that we have on the web.

In addition, we have some CSS specifications that haven’t yet been implemented by a browser or have only been implemented in an experimental way on one browser. We also have some things which are just at the discussion phase, perhaps as a note in the current level of a spec as to where we might take it in future.

So while most of my articles are about things we can do, this one is about things we can’t but that perhaps we might be able to do in the future. Take a look.

Floating Things From Specific Points

On the web, a floated element is taken out of flow and following text wraps around it (due to the line boxes of the following text becoming shortened). Therefore, you only have the option to float a thing to the left or right.

In print, however, you often need to float items to specific places on the page. For example, by floating an element to the top or bottom of a page.

When creating a printed document, you define the size of your pages by using the @page rule, and then your content flows into those pages. By increasing the amount of content or the font size of the text, more pages will be created. Therefore, you might have an element that you know you want to display at the top of the page it appears in, but don’t know exactly on which page it will be.

The CSS Specification that deals with this behavior is called Page Floats. Your image would display in the normal flow of the content — just as on the web — except that the content is fragmented into pages. When the page with the image is encountered, the image is moved out of the normal flow and floated to the top of the page where it appears on. (Content that would have been above the image will display below it and normal flow resumes.)

img { float-reference: page; float: top; } On the left is the image in normal flow, using Page Floats it can be made to appear at the top of the page with the rest of the content coming after it (Large preview)

There is an issue raised against the Page Floats specification to rename it, as there are use cases for this kind of pattern continuous media, e.g. in a multicolumn layout. Currently, if you float an item inside a column, it behaves in the same way as a float in regular normal flow. Assuming there is room, the line boxes of the following items will be shortened and text will wrap around the float within the column.

By using a “page float”, we could float an item to the top of the column that could give you much more control over the placement of elements within the flow of content in a multicolumn context.

Columns are essentially just like pages; we fragment our content between column boxes in the same way that we fragment our content between pages. Therefore, a more generic name would make sense in terms of this behavior being the same for columns and pages.

There are more examples of Page Floats in the excellent exploration of the subject, “Paged Media Approaches: Page Floats” by Julie Blanc.

Overflow In The Block Dimension For Multicol

The concept of “page” floats, would be even more necessary if we were to implement block dimension overflow columns in Multicol. Currently, if you fix the height of a multicol container, additional columns will be created in the inline direction causing an inline scrollbar.

See the Pen Smashing Multicol: overflow columns by Rachel Andrew (@rachelandrew) on CodePen.

See the Pen Smashing Multicol: overflow columns by Rachel Andrew (@rachelandrew) on CodePen.

As I describe in my article “When And How To Use Multiple-Column Layout”, in the CSS Working Group we have considered how we might specify overflow in the block dimension. This would allow us to fix the height of the multicol container in the block dimension, and if there was more content that could fit, create another row of columns below and fill that with content.

How does this tie into Page Floats? Well, in this scenario, you would want more control over where images and other elements end up in these rows of columns. I wouldn’t want, for example, an image to have one line of text below it before the content, and then fragmented to form the next row of columns. Page Floats would enable me to specify that images in that situation would be floated to the bottom of the column or to the top of the first column in the new row.

Spanning n Columns

In the next version of Firefox (Firefox 71), the column-span property from the Multiple-Column Layout specification is implemented, meaning that all of our web browsers implement column-span. The column-span property can take one of two values, all or none. If the value is all, it spans all of the columns; if it is none (which is the initial value), it doesn’t span.

What about multi-column layouts with elements that span some columns? This is a pattern I find in print design quite frequently. The spanning element will generally be at the top or bottom of the page, shortening the columns below or above it.

A quote spans two columns in this article (Large preview)

This is not currently possible on the web, and we don’t have a spec yet for this behavior, however, some print user agents have already implemented an extension to the spec to do this. By using Prince, I can use the following CSS to span two columns:

img { float: column-top-corner; column-span: 2; }

This would enable an element to be floated to the top corner using the Prince version of Page Floats, and then span two of the columns. The rest of the content flows into column boxes as is normal when using multicol. In Prince, the spanning of some columns is tied to floated elements; non-floated elements behave as per the Level 1 multicol spec and can only span all or none.

Specifying this raises some interesting issues. Currently, when we introduce a spanner in multicol, the spanning element essentially creates a row of column boxes above it, and a row of column boxes below. The content doesn’t jump over the spanning element and continue — as you can see in his next CodePen.

See the Pen Smashing Multicol: column-span by Rachel Andrew (@rachelandrew) on CodePen.

See the Pen Smashing Multicol: column-span by Rachel Andrew (@rachelandrew) on CodePen.

What should happen if we have an item spanning two out of three columns that is placed in the middle of the content? In many of the print examples I have seen, the content jumps the spanner when encountering these partial spans, rather than behaving as multicol does today.

In this example, the column content jumps over the spanner and continues. (Large preview)

There are further explorations of column-spanning and extensions ot floats in the CSS Figures Living Idea document. In an older post of mine, I also explored some of these ideas, “Thinking About Page Floats, Figures, Regions And Grids”.

Different Sized Columns In Multicol

Both Flexbox and Grid Layout give us the ability to do columns which are of different sizes that remain in proportion to one another as they flex. Multicol, however, can only split content into equal-sized columns. It is common in print design to have columns of unequal sizes.

Now that Flexbox and Grid have this behavior it makes sense that multicol should follow suit and allow for different column sizes. Perhaps something to consider for level 2 of the Multicol specification.

Text Wrapping All Sides Of An Element

You will have trouble opening a magazine and not spotting something like the image below. Content wrapping all sides of a quote, callout or image. It is a very common pattern and seems reasonable as a pattern we might want to use on the web.

Content wrapping three sides of a floated element in this article in Monocle (Large preview)

We do have a CSS Specification that enables this behavior. CSS Exclusions, at one time bundled with the CSS Shapes specification as CSS Exclusions and Shapes, defines the wrap-flow and wrap-through properties. Exclusions doesn’t define positioning. Instead, you would use it with another positioning method — most likely CSS Grid Layout. This enables a pattern such as in the image below (taken in IE11):

Exclusions in Internet Explorer 11 (Large preview)

Note: If you have a pre-Chromium Edge or Internet Explorer 11 installed, see the CodePen example.

The above example works in Internet Explorer 11 (or pre-Chromium Edge) using the -ms prefixed grid version. Internet Explorer is the only browser to have attempted to implement the property. I am very keen to see implementations of exclusions. I think it solves a number of issues that we have with editorial layouts on the web.

Note: For more, see my post “Editorial Layouts, Exclusions and Grid” or read this issue on the CSS Working Group Drafts repository.

Disconnected Text Flows

Print design often includes content that flows in a similar way to multicol, however, the content boxes are not connected to each other.

You can see an example below from the magazine Monocle:

The content of this article flows between two boxes (Large preview)

This is very difficult to do on the web. If you know how much content you are likely to have, you can make these layouts using Grid in many cases. However, they are then fairly fragile; they rely on us understanding how much content we have and in breaking it up into separate HTML elements. This will usually require us to wrap chunks of content in a div in order to have an element to position on the grid.

A more ideal scenario would be to keep the article as one (properly marked-up thread of content) which could flow into defined areas in the layout.

An article which is then displayed in disconnected areas of the grid

We do have a specification that details something like this: the CSS Regions specification. This was implemented in IE10 (and is therefore in pre-Chromium Edge), and was also in Chrome and WebKit before being removed. Can I use shows the state of affairs.

Can I Use CSS Regions (Large preview)

There were some significant issues with the Regions specification in that it required HTML elements to be present to flow the content into. Unlike multicol, in which anonymous column boxes are generated to hold the content, Regions requires an existing HTML element to host the content. So while you did get the nice behavior of content flowing through these disconnected boxes, you still had to work out how many boxes you needed and create empty divs to hold that content.

Your solution for more content than would fit would be to have a final auto-sized element to “mop up” this extra content without a home. This doesn’t seem like a very elegant solution!

For more information on the problems with the Regions spec as it currently stands, see “CSS Regions Considered Harmful.”

A Future For Regions?

I would be very keen to see something like Regions make a comeback. I think that we know more now about the sorts of layouts that we want to build — now that we have Grid Layout. Regions would enable a sensibly marked-up article to flow through defined boxes in a grid layout, and enable exactly the sort of layouts we see in magazines. From the very simple — skipping a center column that contains a quote or image — to complex sets of boxes and images.

In the Paged Media specification, we have a model for a defined box which is duplicated over and over to create as many pages as needed for the content we have — you don’t need to define those pages upfront. In the developing idea for block dimension overflow columns in multicol, we are considering a model where new rows of columns can be created, as many as are needed until we run out of content. Could we see a future for Regions where we can define a pattern of areas and keep repeating that pattern until we run out of content to fill it?

The article is flowed into the layout, once all the boxes are filled the pattern repeats

Whatever solution is found for Regions, it would reply on solid support for Fragmentation in browsers. Once you break your content across Regions, you will be keen to avoid things like a heading becoming the last thing in a Region — with the associated content somewhere completely disconnected. As with the multicol ideas, I think it would also require support for Page Floats so that we’re able to better control how certain elements display in a Region and stop orphan lines displaying below an image as the content fragments to another Region. In addition Regions would add to the potential of confusing content re-ordering on the web, therefore I think there are a number of related things to get right before we could see a robust and elegant solution to this problem.

Share Your Use Cases

I would love to know if you have use cases for any of the above types of layouts, or if there are other layouts you would love to do but are impossible (or only possible in a fragile way). Let me know in the comments — or even better — write up the issue on your own site and drop a link into the comments section below. Adding new features to CSS starts with understanding what the use cases and requirements are.

You can also follow the discussion on all CSS specifications at the CSS Working Group GitHub repo and Issues List.

Categories: Design

Signs Your Website Feels More Like A Haunted House Than A Welcoming Home

Thu, 10/31/2019 - 03:30
Signs Your Website Feels More Like A Haunted House Than A Welcoming Home Signs Your Website Feels More Like A Haunted House Than A Welcoming Home Suzanne Scacca 2019-10-31T12:30:59+02:00 2019-10-31T12:46:25+00:00

When building a website or PWA, no one ever thinks, “I really hope my visitors run away in fear!” Yet, one wrong move could make a visit to your website seem like a nightmarish walk through a haunted house instead of an awe-inspiring tour of a new home.

To be clear, I’m not talking about dark color palettes or blood-red typography that might remind someone of something they’d seen in a horror movie. If those kinds of design choices make sense and don’t intrude on readability, go for it! What I’m talking about are those ominous feelings emitted by the design and content of a website — similar to the ones someone might feel when walking through a haunted house.

Dr. Frank T. McAndrew answered the question “What Makes a House Feel Haunted?” in an article on Psychology Today back in 2015. He explains:

“From a psychological point of view, the standard features of haunted houses trigger feelings of dread because they push buttons in our brains that evolved long before houses even existed. These alarm buttons warn us of potential danger and motivate us to proceed with caution.”

When a visitor shows up on your website, the last thing you want is for them to be wary of moving through it. You want your website to give off a welcoming and safe vibe; not one that makes visitors wonder what’s lurking around the corner.

So, today, I want to look at some ways in which a website might be giving your visitors the heebie-jeebies and what you can do to eliminate those haunted house-like elements from the experience.

Four Signs Your Website Feels Like A Haunted House

In a lot of ways, a website is like your home. You add comfortable furnishings to it. You make it feel warm and inviting. And you clean up before anyone comes over, so they’re not freaked out by the accumulated dust or clutter.

If you keep that in the back of your mind (i.e. your website = your home), you can avoid these scary missteps as you design websites (as well as PWAs and mobile apps) for your clients.

  1. It Feels Abandoned
  2. It’s Too Confusing
  3. It Looks Too Low Budget
  4. It Looks Unsafe
1. It Feels Abandoned

There’s a video game and movie called Silent Hill that’s based on Centralia, a real ghost town in Pennsylvania. Decades ago, there was a coal mine fire in the town that led to toxic conditions like the gas and smoke that billow up from the ground to this day.

It’s an element the video game designers and cinematographers latched onto when creating their own eerily abandoned setting for Silent Hill:

A still from the movie Silent Hill, featuring the toxic smoke that Centralia is known for. (Source: GIPHY)

Eventually, Centralia was condemned due to the dangers posed by the fire and the resulting toxicity. Today, there are only a few residents who remain in town.

While there are some tourists who venture to Centralia out of curiosity, they don’t stay long. And why would they? The town is unlivable and it’s devoid of any meaningful experiences.

Your website may be sending similar signals if it’s:

  • Too simple in design,
  • Too outdated looking,
  • Devoid of useful content,
  • Seemingly uncared for,
  • Powered only by a basic chatbot,
  • Missing contact details or a working contact form.

The Blockbuster website (which I can’t believe still exists) is a good example of the kinds of signals a website might send to visitors if it were abandoned:

The Blockbuster website has become nothing but a single landing page owned by DISH. (Source: Blockbuster) (Large preview)

The copyright on this website is from 2017, which is why the design of the site isn’t as bad as one might expect it to be. Even the mobile counterpart is responsive:

The nearly defunct Blockbuster still has a decent looking and mobile responsive website. (Source: Blockbuster) (Large preview)

That said, this website is nothing but a husk of what it once was in its heyday.

For example, this is what shows when someone clicks on “Blockbuster Store Location”:

The Blockbuster website advertises a location, but the pop-up leaves visitors with more questions than answers. (Source: Blockbuster) (Large preview)

If I had arrived at this site hoping to find a local video store to rent a movie from, I’d be confused by this pop-up. Does the store actually exist at 211 NE Revere Ave? What’s going to happen when I call the number? And why are they telling me I don’t have to leave the couch?

What DISH should’ve done when buying out Blockbuster is to take ownership of this domain, but then direct it to their own website. As it stands now, it feels as though there’s no one on the other side of this website and there’s no point in keeping it alive (much like the business itself).

It’s these kinds of questions and that eerie feeling of “What’s going on here????” that you want to keep your visitors from experiencing.

2. It’s Too Confusing

Another hallmark of a haunted house is excessive confusion. This is something that real-life serial killer H. H. Holmes mastered with his “Murder Castle”.

“This edifice became Holmes’ booby-trapped Murder Castle. The space featured soundproof rooms, secret passages and a disorienting maze of hallways and staircases. The rooms were also outfitted with trapdoors over chutes that dropped Holmes’ unsuspecting victims to the building’s basement.”

Interestingly, there is a term in the field of environmental psychology related to this particular quality of a space: legibility.

Essentially, if a space (like a home or a website) has clear pathways and a logical organization, it’s much easier for visitors to get oriented. Not only that, if a layout mirrors that of other spaces, it assists in recognizability and comfort. That sounds a lot like the legibility and navigability of a website, right?

Obviously, you don’t want your visitors to feel as though they’re going to get lost in your website or like they’re trapped within the walls of it. There are a number of things that could make them feel this way though:

  • Poor color contrasts,
  • Jarring typography or animations,
  • Excessively deep navigation without a trail of breadcrumbs,
  • Disappearing navigation,
  • Infinite scroll,
  • Incessant pop-ups and disruptions that won’t go away no matter how many times they’re dismissed,
  • An unclear or confusing call-to-action that makes them wonder what happens when they click it.

Let’s look at an example.

How many of you would feel confident pursuing any of the paths (links) available to you on the ARNGREN website?

The ARNGREN website is littered with excessive links and not enough organization. (Source: ARNGREN) (Large preview)

This is what appears when you click on the “PEDALS” image/link in the top-middle of the ARNGREN home page:

An example of one of ARNGREN’s product/category pages. (Source: ARNGREN) (Large preview)

As you can see, the “Index” disappears from the left, so the only option visitors have is to click the home page link or hit the browser “Back” button to depart from the path they’ve taken.

Then there’s the page itself which scrolls on and on, showing off more pictures of bicycles and scooters. There are occasional descriptions and links that appear, but it’s really nothing more than a painful rabbit hole to fall down:

A disorganized and poorly designed page on the ARNGREN website. (Source: ARNGREN) (Large preview)

This website is exactly how I expect visitors of H. H. Holmes’ Murder Castle felt when they first stepped inside those confusing hallways or fell through one of his trap doors. There’s no rhyme or reason to any of the pages and it almost feels as dangerous to backtrack as it is to move forward.

If you’d like to avoid taking your visitors on such a harrowing journey, focus on creating a clear and open path that’s easy to traverse and to get off of when they want to.

3. It Looks Too Low Budget

It’s not just real haunted houses you want to avoid emulating. You should also steer clear of certain types of haunted house attractions.

I’m what you might call a horror addict. I watch scary movies all year long. I take haunted tours every time I visit a new city. And I spend a good chunk of the months of September and October going to haunted house attractions.

As you can imagine, I’ve seen some really impressive haunted houses, and I’ve seen some that are really poorly done.

This, for instance, is an encounter I had with a street actor at Halloween Horror Nights:

That’s me trying not to giggle too hard at the Halloween Horror Nights scare actor. (Source: Halloween Horror Nights) (Large preview)

Although I have a slightly cowered stance, you can see that I'm laughing. That’s because I could see his face through the holes of his mask.

Now, this by no means is a low budget haunted house/Halloween event. And this actor deserves all sorts of kudos for walking around steamy hot Florida in that getup and on stilts, no less. But I will say that being there in the daytime where I could see through the mask did deflate my enthusiasm. It also had me wondering if the rest of the experience would be as disappointing. (For the record, it wasn’t.)

You definitely don’t want your visitors noticing flaws, odd design choices and other errors on your site. Then, wondering why the company behind it didn’t put more money into design and development.

If your website looks cheesy, overdone or like it was cheaply thrown together, you’re going to have a big problem on your hands. The rest of the web has set a very high bar for what a website should look like and how it should work. Fail to live up to those expectations and you’ll find that people will start to question the legitimacy or worth of the business behind it.

For instance, this is the website for Yale University’s School of Art:

This is the home page of the School of Art at Yale University. (Source: Yale University School of Art) (Large preview)

I thought it was a joke, that somehow I’d landed on someone pretending to be Yale University at instead of But I was wrong. This is the real website of the art department at the Ivy League university.

So, I dug a little further, hoping that somewhere on this subdomain would be an explanation of why this website sucked so much. This is what I found:

The Yale School of Art explains why their website / wiki looks the way it does. (Source: Yale University School of Art) (Large preview)

Let me point you to the most revealing parts of the explanation. First, they explain that this site is an open-source wiki:

It is a wiki, meaning that every graduate student, staff person, and faculty member of the School can change this website’s content or add to it at any time.

Next, they warn you that you may be shocked by what you see:

As you move through it you may, in consequence of such openness, encounter content that surprises you or with which you don’t agree. That will be the sign that this website reflects life in our institution in all its heterogeneous dimensions.

Considering the editor of this page used a negative review from Facebook as the repeating background image, there must be some inside joke here. In fact, when I looked into it further, it seems as though this school has had a tradition of scary web design choices as far back as 2010. So, they obviously know what they’re doing.

Here’s the thing though: even if you’re designing for someone with as well-known a reputation as Yale, building something that looks like it was thrown together in Paint back in 2001 is no way to go. There’s no exception for design this bad and I don’t think your visitors will be happy that you wasted their time either.

I realize this might help with the virality of a site, but it’ll do nothing for the credibility of it. All you’ll end up with is a few thrill seekers stumbling through in search of a good laugh or shock. What you need instead is visitors who feel comfortable and confident enough to convert.

4. It Looks Unsafe

The last thing that might leave people feeling unsettled is a lack of security (or at least the perception of none).

One of the things I often get asked by people who don’t like scary movies or going to haunted houses is:

“But aren’t you scared?”

Of course, I’m scared! I enjoy all of this horror stuff because I can do so safely from a distance. I know that the scare actors in a haunted house aren’t going to hurt me and I know that Michael Myers isn’t going to pop out of my TV screen and butcher me in the middle of the night. Plus, it’s a much more enjoyable way to get my cardio in without having to hit the treadmill.

A still of Michael Myers sneaking up on Laurie Strode in Halloween. (Source: GIPHY)

I think for some people, though, they don’t have that same sense of security when partaking in activities like these, which is why they steer clear. And this is something you need to be extra careful about when it comes to your website. Specifically, be mindful of:

  • Installing SSL certificates on every website.
  • Using security badges at checkout.
  • Preventing 404 errors.
  • Fixing faulty contact forms.
  • Blocking spam in comment sections and forums.
  • Monitoring for server downtime.
  • Repairing the white screen of death.

Let’s look at an example of a website that sends a number of red flags pertaining to security. This is RoadKill T-Shirts:

This is the home page of the RoadKill T-Shirts website. (Source: RoadKill T-Shirts) (Large preview)

At first glance, you might think this e-commerce website is okay. The design is outdated, but it’s a low-end tee-shirt shop. Visitors can’t be expecting too much from the design.

But then you move over to your mobile device and realize it’s not responsive:

The RoadKill T-Shirts website is not mobile responsive. (Source: RoadKill T-Shirts) (Large preview)

That said, there may be some visitors who are able to look past these design missteps, especially if there’s a tee shirt decal they really want.

One of the first red flags that should stop them in their tracks though is the “Not Secure” notice in their browser window. Although there is a GoDaddy security seal at the very bottom of the checkout page, I’m not all that sure I’d trust that to protect my purchase as a consumer either.

The RoadKill T-Shirts website includes a GoDaddy security seal at checkout. (Source: RoadKill T-Shirts) (Large preview)

Then, there’s the matter of the contact form. I was curious to see how secure users would feel about filling in contact information without submitting a payment, so I forced an error:

What the RoadKill T-Shirts contact form looks like when an error occurs. (Source: RoadKill T-Shirts) (Large preview)

I’m happy to see that the failure to fill in required fields triggered such a response. However, here’s what happens to the bottom of the form as a result:

RoadKill T-Shirts error-filled contact form leads to a hidden “Submit” button. (Source: RoadKill T-Shirts) (Large preview)

Users can tab down to reveal the “Submit” button. However, what if your visitors don’t know that they can do that? They may just end up abandoning the form and the website altogether if something as simple as the contact form is so fraught with error.

There are a variety of ways a website might seem unsafe to visitors, so do what you can to fortify it on the backend and then provide trust marks on the frontend to put their minds at ease.

Wrapping Up

When a visitor enters your website, what do you want their first thought to be?

“Oh great! There’s the product I was looking for!”


“Hmmm... Maybe I should go back to Google and see if there’s a different place to buy this product from.”

There are so many ways to give your visitors pause when they visit a website. But if you start looking at your website like a home, you can avoid the common pitfalls that make a website feel more like a haunted house than a warm and welcome homecoming.

(ra, yk, il)
Categories: Design

Creativity Sparks Shining Through The Fog (November 2019 Wallpapers Edition)

Thu, 10/31/2019 - 03:00
Creativity Sparks Shining Through The Fog (November 2019 Wallpapers Edition) Creativity Sparks Shining Through The Fog (November 2019 Wallpapers Edition) Cosima Mielke 2019-10-31T12:00:00+02:00 2019-10-31T12:46:25+00:00

The fascinating world of aviation, classic movies, sweet childhood memories — these are just some of the things that inspired artists and designers from across the globe to participate in our wallpapers challenge this time around.

The monthly challenge has been going on for more than nine years already and we are very thankful to everyone who tickles their creativity each month anew to keep the steady stream of wallpapers flowing and caters for some colorful inspiration with their artwork — no matter how gray the weather outside might be.

The wallpapers in this collection come in versions with and without a calendar for November 2019, so it’s up to you to decide if you want to keep things minimalistic or have an overview of the month at a glance. As a bonus goodie, we also compiled a little best-of from past November editions at the end of the post. Maybe you’ll rediscover some long-forgotten favorites in there? Happy November!

Please note that:

  • All images can be clicked on and lead to the preview of the wallpaper,
  • We respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience through their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us but rather designed from scratch by the artists themselves.
Submit your wallpaper

We are always looking for designers and artists to be featured in our wallpapers posts. So if you have an idea for a December wallpaper, please don’t hesitate to submit your design. We’d love to see what you’ll come up with. Join in! →

International Civil Aviation Day

“On December 7, we mark International Civil Aviation Day, celebrating those who prove day by day that the sky really is the limit. As the engine of global connectivity, civil aviation is now, more than ever, a symbol of social and economic progress and a vehicle of international understanding. This monthly calendar is our sign of gratitude to those who dedicate their lives to enabling everyone to reach their dreams.” — Designed by PopArt Studio from Serbia.

Don’t Let Gray Win

“Let’s take extra care of colors during the autumn months. November might be gray and rainy. Outside. Don’t let it inside. Take a good book, prepare a hot ginger tea, and cover your knees with a bright woolen plaid.” — Designed by Tartanify from France.

Before Sunset In Paris

“The inspiration came from the movies of Woody Allen and his amazing cinematography, the framing idea came from the polaroid photos.” — Designed by João Pinto from Portugal.


“November is the month of my birth so it reminds me of so many good things. The scent and the beautiful red colors of pomegranate seeds. The beauty of their trees with tiny leaves. The magical colors of autumn take me to the orchards on the farm and my family together under the sun and clouds. Laughings and pumpkins on the floor while the sheets were hung to dry on the clothesline. Cousins playing and collecting leaves. Sweet November.” — Designed by Carmen Navalhas from Portugal.

Seasonal Sunsets

“Fall is such a beautiful time of year so I designed a wallpaper inspired by fall’s seasonal colors and amazing sunsets.” — Designed by Kassandra Escoe from Maryland.

No-Shave November

“The goal of No-Shave November is to grow awareness by embracing our hair, which many cancer patients lose, and letting it grow wild and free. Donate the money you typically spend on shaving and grooming to educate about cancer prevention, save lives, and aid those fighting the battle.” — Designed by Tatiana Ignatieva from Portugal.

Fishing At Sunset

“November is a month for calm. It’s cold and we enjoy fishing with lions.” — Designed by Veronica Valenzuela from Spain.

The Power Of Imagination

Designed by Ricardo Gimenes from Sweden.

Oldies But Goodies

Some things are just too good to gather dust. Hidden in our wallpaper archives we rediscovered some November favorites from past years. Ready for a trip back in time? (Please note that these designs don’t come with a calendar.)

Outer Space

“This November, we are inspired by the nature around us and the universe above us, so we created an out-of-this-world calendar. Now, let us all stop for a second and contemplate on preserving our forests, let us send birds of passage off to warmer places, and let us think to ourselves — if not on Earth, could we find a home somewhere else in outer space?” — Designed by PopArt Studio from Serbia.


“I don’t know anyone who hasn’t enjoyed a cold night looking at the stars.” — Designed by Ema Rede from Portugal.

The Kind Soul

“Kindness drives humanity. Be kind. Be humble. Be humane. Be the best of yourself!” — Designed by Color Mean Creative Studio from Dubai.

Autumn Darkness

“‘When autumn darkness falls, what we will remember are the small acts of kindness: a cake, a hug, an invitation to talk, and every single rose. These are all expressions of a nation coming together and caring about its people.’ (Jens Stoltenberg)” — Designed by Dipanjan Karmakar from India.

Tempestuous November

“By the end of autumn, ferocious Poseidon will part from tinted clouds and timid breeze. After this uneven clash, the sky once more becomes pellucid just in time for imminent luminous snow.” — Designed by Ana Masnikosa from Belgrade, Serbia.

Peanut Butter Jelly Time!

“November is the Peanut Butter Month so I decided to make a wallpaper around that. As everyone knows peanut butter goes really well with some jelly so I made two sandwiches, one with peanut butter and one with jelly. Together they make the best combination. I also think peanut butter tastes pretty good so that’s why I chose this for my wallpaper.” — Designed by Senne Mommens from Belgium.

Music From Nature

Designed by StarAdmin from India.

The Most Productive Month

“Working hard or hardly working? What will your work stats look like in November?” Designed by Photo Stats from Sweden.

Curious Squirrel

Designed by Saul Wauters from Belgium.

Fall Breeze

“The colorful leaves and cool breeze that make you want to snuggle in your couch at home inspired me to create this fall design.” — Designed by Allison Coyle from the United States.

Autumn In Paris

Designed by Lia Pantazi from Greece.

World Kindness Day

“World Kindness Day is November 13, and I wanted to share this saying to remind others to never underestimate the power of a kind word.” — Designed by Shawna Armstrong from the United States.

Coffee Time

“It’s the time for being at home and enjoying the small things… I love having a coffee while watching the rain outside my window.” — Designed by Veronica Valenzuela from Spain.

Thanks & Giving

“Wishing everyone a holiday season filled with both Thanks & Giving!” — Designed by Jordan Thoma from the United States.

On The Edge Of Forever

“November has always reminded me of the famous Guns N’ Roses song, so I’ve decided to look at its meaning from a different perspective. The story in my picture takes place somewhere in space, where a young guy beholds a majestic meteor shower and wonders about the mysteries of the universe.” — Designed by Aliona Voitenko from Ukraine.

November Ingredients

“Whether or not you celebrate Thanksgiving, there’s certain things that always make the harvest season special. As a Floridian, I’m a big fan of any signs that the weather might be cooling down soon, too!” — Designed by Dorothy Timmer from the United States.

All Lines Point To November

“November often means rain and cold temps, but there’s beauty to be found in that as I found in this moment — the wet lines lead the way.” — Designed by Aisha Souto-Maior, Paris-based, NY-bred.

Simple Leaves

Designed by Nicky Somers from Belgium.


“It’s cold in November, so you have to stay closer. Also: Inktober and American Horror Story.” — Designed by Anja Sturm from Germany.

The Collection Of Birds

“The collection of birds are my travels. At each destination I buy a wood, bronze, stone bird, anything the local bazaars sell. I have all gathered at a modest vitrine in my house. I have so much loved my collection that, after taking pictures of them, I designed each one, then created a wallpaper and overdressed a wall of my living room. Now my thought is making them as a desktop wallpaper and give them to you as a gift.” — Designed by Natasha Kamou from Greece.

First Icicles Of The Coming Winter

Designed by Aleksandra Sivoronova from Latvia.

Autumn Impression

Designed by Agnieszka Malarczyk from Poland.


“Here is a wallpaper that celebrates the arrival of spring in the southern hemisphere.” Designed by Finxduvey from Argentina.

Join In Next Month!

Thank you to all designers for their participation. Join in next month!

Categories: Design
©2019 Richard Esmonde. All rights reserved.