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

dreamt up by webguru in Uncategorized | Comments Off on 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)

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

Fernando Doglio

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 socket.io (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 socket.io 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 socket.io 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 socket.io’s rooms feature which handles individual rooms for us.
  • Because of how socket.io 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('socket.io')(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('chat.events.NEWMSG'), (data, done) => {
    let room = socket.roomname
    if(!socket.roomname) {
        socket.emit(config.get('chat.events.NEWMSG'), "You're not part of a room yet")
        return done()

    // we tell the client to execute 'new message'
    socket.to(socket.roomname).emit(config.get('chat.events.NEWMSG'), {
      room: room,
      username: socket.username,
      message: data

  socket.on(config.get('chat.events.JOINROOM'), (data, done) => {
      console.log("Requesting to join a room: ", data)

      socket.roomname = data.roomname
      socket.username = data.username
      socket.join(data.roomname, _ => {
          socket.to(data.roomname).emit(config.get('chat.events.NEWMSG'), {
            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) {

      // echo globally that this client has left
      socket.to(socket.roomname).emit('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('chat.events.NEWMSG'). 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('chat.events.JOINROOM') listener. In that case, all we do is add the user to the room (again, this is handled by socket.io, 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 socket.io, 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) {
                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 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('socket.io-client'),
    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
        }, _ => {
            logger.info("Room joined!")
            gamestate.inroom = true
            done(null, {
                event: config.get('chatserver.commands.JOINROOM')

   handleCommand: function(command, gamestate, done) {
        logger.info("Sending command to chatserver!")
        let message = command.split(" ").splice(1).join(" ")

        logger.info("Message to send: ", message)

        if(!gamestate.inroom) { //first time sending the message, so join the room first
            logger.info("Joining a room")
            let gameId = gamestate.game
    socket.emit(config.get("chatserver.commands.JOINROOM") , {
                roomname: gamestate.gameID,
                username: gamestate.playername
            }, _ => {
                logger.info("Room joined!")
                gamestate.inroom = true
                updateGameState = true

                logger.info("Updating game state ...")
                socket.emit(config.get("chatserver.commands.SENDMSG"), message, done)
        } else {
            logger.info("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:

Smashing Editorial
(dm, yk, il)

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

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

dreamt up by webguru in Uncategorized | Comments Off on 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?

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

Drew McLellan

Liz Elcoate 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


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 elizabethelcoate.com, 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.

Smashing Editorial
(dm, ra, il)

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

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

dreamt up by webguru in Uncategorized | Comments Off on Smashing Podcast Episode 1 With Andy Clarke: What Is Art Direction?

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

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

Drew McLellan

Andy Clarke 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


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 gov.uk 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 gov.uk and I’ve always thought of gov.uk as being the website that design forgot. I’ve often said gov.uk, 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, “Gov.uk.”

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 gov.uk 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 gov.uk 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 gov.uk 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 gov.uk.” 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 gov.uk, 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, stuffandnonsense.co.uk. Art Direction for the Web is available now through Smashing at smashingmagazine.com/books and I commend it to you. Andy, do you have any parting words?

Andy Clarke: (Beep) to Brexit.

Smashing Editorial
(dm, ra, il)

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

Build A Seamless Spreadsheet Import Experience With The Help Of Flatfile.io

dreamt up by webguru in Uncategorized | Comments Off on Build A Seamless Spreadsheet Import Experience With The Help Of Flatfile.io

Build A Seamless Spreadsheet Import Experience With The Help Of Flatfile.io

Build A Seamless Spreadsheet Import Experience With The Help Of Flatfile.io

Suzanne Scacca

(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?

Text: inefficient import examples from Flatfile

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.

Flatfile fixes data import issues
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.

Microsoft Azure data import guide

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):

Flatfile CRM data import demo

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:

Go1 provides support for CSV upload failure

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:

Nimble provides support for CSV upload failure

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.

Flatfile demo of multi-file upload

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 answer about CSV file import error

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.

MailChimp mapping fail

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.

ClickUp data import page

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:

ClickUp data import column identification

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:

Smart column-matching system in ClickUp data import

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:

ClickUp data import label matching

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:

ClickUp data import cleanup

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.

Flatfile makes data import simple for developers

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:

Flatfile demo

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:

Flatfile code snippet for contact list import

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:

Flatfile code snippet for data import validation

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.

Smashing Editorial
(ms, ra, yk, il)

Source: Smashing Magazine, Build A Seamless Spreadsheet Import Experience With The Help Of Flatfile.io

Creating Online Environments That Work Well For Older Users

dreamt up by webguru in Uncategorized | Comments Off on Creating Online Environments That Work Well For Older Users

Creating Online Environments That Work Well For Older Users

Creating Online Environments That Work Well For Older Users

Barry Rueger

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.

Older man using computer

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.

Samples of type contrast

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 laptop computer

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 Amazon.com 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.

Smashing Editorial
(dm, yk, il)

Source: Smashing Magazine, Creating Online Environments That Work Well For Older Users

Things We Can’t (Yet) Do In CSS

dreamt up by webguru in Uncategorized | Comments Off on Things We Can’t (Yet) Do In CSS

Things We Can’t (Yet) Do In CSS

Things We Can’t (Yet) Do In CSS

Rachel Andrew

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;

A diagram showing two pages, one with an image partway through the content the other with the image at the 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 photograph of a three column magazine layout, with a quote spanning two columns

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.

A photograph of a magazine article

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.

The article title is centered and wrapped by text set as two columns

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):

An image wrapped on all sides with text

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:

A photograph of a magazine article with text, quotes and images in boxes

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.

A diagram showing some content on one side, which is then displayed in different boxes of the grid

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.

Chart showing that Regions was in several browsers but has now been removed

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?

A diagram showing a longer article flowing through two grids of boxes

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.

Smashing Editorial

Source: Smashing Magazine, Things We Can’t (Yet) Do In CSS

Collective #562

dreamt up by webguru in Uncategorized | Comments Off on Collective #562

#pad-img-desktop {
background: url(“https://pa.pvd.to/serve/6dCskA?email=*|EMAIL|*&campaign_id=*|CAMPAIGN_UID|*”) no-repeat center !important;
width: 564px !important;
height: 526px !important;
#pad-mobile {display: none !important;}
#pad-desktop {display: block !important;}

@media only screen and (max-width: 489px) {
#pad-img-mobile {
background: url(“https://pa.pvd.to/serve/oyoJMA?email=*|EMAIL|*&campaign_id=*|CAMPAIGN_UID|*”) no-repeat center !important;
background-size: 100% auto !important;
width: 300px !important;
height: 599px !important;
#pad-mobile {display: block !important;}
#pad-desktop {display: none !important;}
#pad-img-desktop {background: none !important;}


Behind the scenes of We Cargo

Some fantastic tech insights to the new wecargo.be website made by EPIC that we picked as the Website of the Week. An article by Luigi De Rosa.

Read it



A curated royalty-free illustration library great for products, brands and presentations.

Check it out


Neural Synesthesia

An amazing project by Xander Steenbrugge that is an attempt to explore new approaches to audiovisual experience based on Artificial Intelligence.

Check it out

Collective #562 was written by Pedro Botelho and published on Codrops.

Source: Codrops, Collective #562

Signs Your Website Feels More Like A Haunted House Than A Welcoming Home

dreamt up by webguru in Uncategorized | Comments Off on 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

Signs Your Website Feels More Like A Haunted House Than A Welcoming Home

Suzanne Scacca

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.
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

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:

Blockbuster website on mobile

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”:

BlockBuster location pop-up

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?

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:

ARNGREN category 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:

ARNGREN text, links, and images

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:

Halloween Horror Nights scare actor

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:

Yale University’s art department website

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 yale.net instead of yale.edu. 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:

Yale School of Art web design

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.
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:

RoadKill T-Shirts website

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:

RoadKill T-Shirts not responsive on mobile

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.

RoadKill T-Shirts GoDaddy security seal

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:

RoadKill T-Shirts contact form 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 on form

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.

Smashing Editorial
(ra, yk, il)

Source: Smashing Magazine, Signs Your Website Feels More Like A Haunted House Than A Welcoming Home

Creativity Sparks Shining Through The Fog (November 2019 Wallpapers Edition)

dreamt up by webguru in Uncategorized | Comments Off on Creativity Sparks Shining Through The Fog (November 2019 Wallpapers Edition)

Creativity Sparks Shining Through The Fog (November 2019 Wallpapers Edition)

Creativity Sparks Shining Through The Fog (November 2019 Wallpapers Edition)

Cosima Mielke

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.

International Civil Aviation Day

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.

Don’t Let Gray Win

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.

Before Sunset In Paris


“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.

Seasonal Sunsets

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.

No Shave November

Fishing At Sunset

“November is a month for calm. It’s cold and we enjoy fishing with lions.” — Designed by Veronica Valenzuela from Spain.

Fishing At Sunset

The Power Of Imagination

Designed by Ricardo Gimenes from Sweden.

The Power Of Imagination

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.

Outer Space


“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.

The Kind Soul

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.

Autumn Darkness

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.

Tempestuous November

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.

Peanut Butter Jelly Time!

Music From Nature

Designed by StarAdmin from India.

Music From Nature

The Most Productive Month

“Working hard or hardly working? What will your work stats look like in November?” Designed by Photo Stats from Sweden.

Smashing Wallpaper - november 11

Curious Squirrel

Designed by Saul Wauters from Belgium.

Curious Squirrel

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.

Fall Breeze

Autumn In Paris

Designed by Lia Pantazi from Greece.

Autumn In Paris

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.

World Kindness Day

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.

Coffee Time

Thanks & Giving

“Wishing everyone a holiday season filled with both Thanks & Giving!” — Designed by Jordan Thoma from the United States.

Thanks & Giving

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.

On The Edge of Forever

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.

November Ingredients

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.

All lines point to November

Simple Leaves

Designed by Nicky Somers from Belgium.

Simple Leaves


“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.

The Collection of Birds

First Icicles Of The Coming Winter

Designed by Aleksandra Sivoronova from Latvia.

Smashing Wallpaper - november 12

Autumn Impression

Designed by Agnieszka Malarczyk from Poland.

Smashing Wallpaper - november 11


“Here is a wallpaper that celebrates the arrival of spring in the southern hemisphere.” Designed by Finxduvey from Argentina.

Smashing Wallpaper - november 12

Join In Next Month!

Thank you to all designers for their participation. Join in next month!

Source: Smashing Magazine, Creativity Sparks Shining Through The Fog (November 2019 Wallpapers Edition)

Writing A Multiplayer Text Adventure Engine In Node.js: Creating A Text-Based Client For The Server (Part 3)

dreamt up by webguru in Uncategorized | Comments Off on Writing A Multiplayer Text Adventure Engine In Node.js: Creating A Text-Based Client For The Server (Part 3)

Writing A Multiplayer Text Adventure Engine In Node.js: Creating A Text-Based Client For The Server (Part 3)

Writing A Multiplayer Text Adventure Engine In Node.js: Creating A Text-Based Client For The Server (Part 3)

Fernando Doglio

I first showed you how to define a project such as this one, and gave you the basics of the architecture as well as the mechanics behind the game engine. Then, I showed you the basic implementation of the engine — a basic REST API that allows you to traverse a JSON-defined world.

Today, I’m going to be showing you how to create an old-school text client for our API by using nothing other than Node.js.

Reviewing The Original Design

When I first proposed a basic wireframe for the UI, I proposed four sections on the screen:

(Large preview)

Although in theory that looks right, I missed the fact that switching between sending game commands and text messages would be a pain, so instead of having our players switching manually, we’ll have our command parser make sure it is capable of discerning whether we’re trying to communicate with the game or our friends.

So, instead of having four sections in our screen, we’ll now have three:

(Large preview)

That is an actual screenshot of the final game client. You can see the game screen on the left, and the chat on the right, with a single, common input box at the bottom. The module we’re using allows us to customize colors and some basic effects. You’ll be able to clone this code from Github and do what you want with the look and feel.

One caveat though: Although the above screenshot shows the chat working as part of the application, we’ll keep this article focused on setting up the project and defining a framework where we can create a dynamic text-UI based application. We’ll focus on adding chat support on the next and final chapter of this series.

The Tools We’ll Need

Although there are many libraries out there that let us create CLI tools with Node.js, adding a text-based UI is a completely different beast to tame. Particularly, I was able to find only one (very complete, mind you) library that would let me do exactly what I wanted: Blessed.

This library is very powerful and provides a lot of features we won’t be using for this project (such as casting shadows, drag&drop, and others). It basically re-implements the entire ncurses library (a C library which allows developers to create text-based UIs) which has no Node.js bindings, and it does so directly in JavaScript; so, if we had to, we could very well check out its internal code (something I wouldn’t recommend unless you absolutely had to).

Although the documentation for Blessed is quite extensive, it mainly consists of individual details about each method provided (as opposed to having tutorials explaining how to actually use those methods together) and it is lacking examples everywhere, so it might be difficult to dig into it if you have to understand how a particular method works. With that being said, once you understand it for one, everything works the same way, which is a big plus since not every library or even language (I’m looking at you, PHP) has a consistent syntax.

But documentation aside; the big plus for this library is that it works based on JSON options. For example, if you wanted to draw a box on the top right corner of the screen, you would do something like this:

var box = blessed.box({
  top: ‘0',
  right: '0',
  width: '50%',
  height: '50%',
  content: 'Hello {bold}world{/bold}!',
  tags: true,
  border: {
    type: 'line'
  style: {
    fg: 'white',
    bg: 'magenta',
    border: {
      fg: '#f0f0f0'
    hover: {
      bg: 'green'

As you can imagine, other aspects of the box are defined there as well (such as it’s size), which can perfectly be dynamic based on the terminal’s size, type of border and colors — even for hover events. If you’ve done front-end development at some point, you’ll find a lot of overlap between the two.

The point I’m trying to make here is that everything regarding the representation of the box is configured through the JSON object passed to the box method. That, to me, is perfect because I can easily extract that content into a configuration file, and create a business logic capable of reading it and deciding which elements to draw on screen. Most importantly, it will help us get a glimpse of how they’ll look once they’ve been drawn.

This will be the base for the entire UI aspect of this module (more on that in a second!).

Architecture Of The Module

The main architecture of this module relies entirely on the UI widgets which we’ll be showing. A group of these widgets is considered a screen, and all these screens are defined in a single JSON file (which you can find inside the /config folder).

This file has over 250 lines, so showing it here makes no sense. You can look at the full file online, but a small snippet from it looks like this:

"screens": {
        "main-options": {
            "file": "./main-options.js",
            "elements": {
                "username-request": {
                    "type": "input-prompt",
                    "params": {
                        "position": {
                            "top": "0%",
                            "left": "0%",
                            "width": "100%",
                            "height": "25%"
                        "content": "Input your username: ",
                        "inputOnFocus": true,
                        "border": {
                          "type": "line"
                        "style": {
                          "fg": "white",
                          "bg": "blue",
                          "border": {
                              "fg": "#f0f0f0"
                          "hover": {
                            "bg": "green"
                "options": {
                    "type": "window",
                    "params": {
                        "position": {
                            "top": "25%",
                            "left": "0%",
                            "width": "100%",
                            "height": "50%"
                        "content": "Please select an option: n1. Join an existing game.n2. Create a new game",
                        "border": {
                          "type": "line"
                        "style": {
                "input": {
                    "type": "input",
                    "handlerPath": "../lib/main-options-handler",

The “screens” element will contain the list of screens inside the application. Each screen contains a list of widgets (which I’ll cover in a bit) and every widget has its blesses-specific definition and related handler files (when applicable).

You can see how every “params” element (inside a particular widget) represents the actual set of parameters expected by the methods we saw earlier. The rest of the keys defined there help provide context about what type of widgets to render and their behavior.

A few points of interest:

Screen Handlers

Every screen element has file property which references the code associated to that screen. This code is nothing but an object that must have an init method (the initialization logic for that particular screen takes place inside of it). Particularly, the main UI engine, will call that init method of every screen, which in turn, should be responsible for initializing whatever logic it may need (i.e setting up the input boxes events).

The following is the code for the main screen, where the application requests the player to select an option to either start a brand new game or join an existing one:

const logger = require("../utils/logger")

module.exports = {
    init: function(elements, UI) {
        this.elements = elements
        this.UI = UI
        this.id = "main-options"

    moveToIDRequest: function(handler) {
        return this.UI.loadScreen('id-requests', (err, ) => {

    createNewGame: function(handler) {
        handler.createNewGame(this.UI.gamestate.APIKEY, (err, gameData) => {
              this.UI.gamestate.gameID = gameData._id
              handler.joinGame(this.UI.gamestate, (err) => {
                return this.UI.loadScreen('main-ui', {
                    flashmessage: "You've joined game " + this.UI.gamestate.gameID + " successfully"
                },  (err, ) => {

    setInput: function() {
        let handler = require(this.elements["input"].meta.handlerPath)
        let input = this.elements["input"].obj
        let usernameRequest = this.elements['username-request'].obj
        let usernameRequestMeta = this.elements['username-request'].meta
        let question = usernameRequestMeta.params.content.trim()



         let validOptions =  {
             1: this.moveToIDRequest.bind(this),
             2: this.createNewGame.bind(this)

        usernameRequest.on('submit', (username) => {

            logger.info("Username:" +username)
            logger.info("Playername: " + username.replace(question, ''))
            this.UI.gamestate.playername = username.replace(question, '')


            input.on('submit', (data) => {
                let command = input.getValue()
                  if(!validOptions[+command]) {
                      this.UI.setUpAlert("Invalid option: " + command)
                      return this.UI.renderScreen()
                  return validOptions[+command](handler)

        return input

As you can see, the init method calls the setupInput method which basically configures the right callback to handle user input. That callback holds the logic to decide what to do based on the user’s input (either 1 or 2).

Widget Handlers

Some of the widgets (usually input widgets) have a handlerPath property, which references the file containing the logic behind that particular component. This is not the same as the previous screen handler. These don’t care about the UI components that much. Instead, they handle the glue logic between the UI and whatever library we’re using to interact with external services (such as the game engine’s API).

Widget Types

Another minor addition to the JSON definition of the widgets is their types. Instead of going with the names Blessed defined for them, I’m creating new ones in order to give me more wiggle room when it comes to their behavior. After all, a window widget might not always “just display information”, or an input box might not always work the same way.

This was mostly a preemptive move, just to ensure I have that ability if I ever need it in the future, but as you’re about to see, I’m not using that many different types of components anyway.

Multiple Screens

Though the main screen is the one I showed you in the screenshot above, the game requires a few other screens in order to request things such as your player name or whether you’re creating a brand new game session or even joining an existing one. The way I handled that was, again, through the definition of all these screens in the same JSON file. And to move from one screen into the next one, we use the logic inside the screen handler files.

We can do this simply by using the following line of code:

this.UI.loadScreen('main-ui', (err ) => {
 if(err) this.UI.setUpAlert(err)    

I’ll show you more details about the UI property in a second, but I’m just using that loadScreen method to re-render the screen and picking the right components off of the JSON file using the string passed as parameter. Very straightforward.

Code Samples

It’s now time to check out the meat and potatoes of this article: the code samples. I’m just going to highlight what I think are the small gems inside it, but you can always take a look at the full source code directly in the repository anytime.

Using Config Files To Auto Generate The UI

I’ve already covered part of this, but I think it’s worth exploring the details behind this generator. The gist behind it (file index.js inside the /ui folder) is that it is a wrapper around the Blessed object. And the most interesting method inside it, is the loadScreen method.

This method grabs the configuration (through the config module) for one specific screen and goes through its content, trying to generate the right widgets based on each element’s type.

loadScreen: function(sname, extras, done) {
        if(typeof extras == "function") {
            done = extras

        let screen = config.get('screens.' + sname)
        let screenElems = {}
        if(this.screenElements.length > 0) { //remove previous screen
            this.screenElements.map( e => e.detach())

        Object.keys(screen.elements).forEach( eName => {
            let elemObj = null
            let element = screen.elements[eName]
            if(element.type == 'window') {
                elemObj = this.setUpWindow(element)
            if(element.type == 'input') {
                elemObj = this.setUpInputBox(element)

            if(element.type == 'input-prompt') {
                elemObj = this.setUpInputBox(element)
            screenElems[eName] = {
                meta: element,
                obj: elemObj

        if(typeof extras === 'object' && extras.flashmessage) {

        let logicPath = require(screen.file)
        logicPath.init(screenElems, this)

As you can see, the code is a bit lengthy, but the logic behind it is simple:

  1. It loads the configuration for the current specific screen;
  2. Cleans up any previously existing widgets;
  3. Goes over every widget and instantiates it;
  4. If an extra alert was passed as a flash message (which is basically a concept I stole from Web Dev in which you setup a message to be shown on screen until the next refresh);
  5. Render the actual screen;
  6. And finally, require the screen handler and execute it’s “init” method.

That’s it! You can check out the rest of the methods — they’re mostly related to individual widgets and how to render them.

Communication Between UI And Business Logic

Although in the grand scale, the UI, the back-end and the chat server all have a somewhat layered-based communication; the front end itself needs at least a two-layered internal architecture in which the pure UI elements interact with a set of functions that represent the core logic inside this particular project.

The following diagram shows the internal architecture for the text client we’re building:

(Large preview)

Let me explain it a bit further. As I mentioned above, the loadScreenMethod will create UI presentations of the widgets (these are Blessed objects). But they are contained as part of the screen logic object which is where we set up the basic events (such as onSubmit for input boxes).

Allow me to give you a practical example. Here is the first screen you see when starting the UI client:

(Large preview)

There are three sections on this screen:

  1. Username request,
  2. Menu options / information,
  3. Input screen for the menu options.

Basically, what we want to do is to request the username and then ask them to pick one of the two options (either starting up a brand new game or joining an existing one).

The code that takes care of that is the following:

module.exports = {

    init: function(elements, UI) {
        this.elements = elements
        this.UI = UI
        this.id = "main-options"

    moveToIDRequest: function(handler) {
        return this.UI.loadScreen('id-requests', (err, ) => {

    createNewGame: function(handler) {

        handler.createNewGame(this.UI.gamestate.APIKEY, (err, gameData) => {
              this.UI.gamestate.gameID = gameData._id
              handler.joinGame(this.UI.gamestate, (err) => {
                return this.UI.loadScreen('main-ui', {
                    flashmessage: "You've joined game " + this.UI.gamestate.gameID + " successfully"
                },  (err, ) => {

    setInput: function() {
        let handler = require(this.elements["input"].meta.handlerPath)
        let input = this.elements["input"].obj
        let usernameRequest = this.elements['username-request'].obj
        let usernameRequestMeta = this.elements['username-request'].meta
        let question = usernameRequestMeta.params.content.trim()



         let validOptions =  {
             1: this.moveToIDRequest.bind(this),
             2: this.createNewGame.bind(this)

        usernameRequest.on('submit', (username) => {

            logger.info("Username:" +username)
            logger.info("Playername: " + username.replace(question, ''))
            this.UI.gamestate.playername = username.replace(question, '')


            input.on('submit', (data) => {
                let command = input.getValue()
                  if(!validOptions[+command]) {
                      this.UI.setUpAlert("Invalid option: " + command)
                      return this.UI.renderScreen()
                  return validOptions[+command](handler)



        return input

I know that’s a lot of code, but just focus on the init method. The last thing it does is to call the setInput method which takes care of adding the right events to the right input boxes.

Therefore, with these lines:

let handler = require(this.elements["input"].meta.handlerPath)
let input = this.elements["input"].obj
let usernameRequest = this.elements['username-request'].obj
let usernameRequestMeta = this.elements['username-request'].meta
let question = usernameRequestMeta.params.content.trim()

We’re accessing the Blessed objects and getting their references, so that we can later set up the submit events. So after we submit the username, we’re switching focus to the second input box (literally with input.focus() ).

Depending on what option we choose from the menu, we’re calling either of the methods:

  • createNewGame: creates a new game by interacting with its associated handler;
  • moveToIDRequest: renders the next screen in charge of requesting the game ID to join.

Communication With The Game Engine

Last but certainly not least (and following the above example), if you hit 2, you’ll notice that the method createNewGame uses the handler’s methods createNewGame and then joinGame (joining the game right after creating it).

Both these methods are meant to simplify the interaction with the Game Engine’s API. Here is the code for this screen’s handler:

const request = require("request"),
    config = require("config"),
    apiClient = require("./apiClient")

let API = config.get("api")
module.exports = {

    joinGame: function(apikey, gameId, cb) {
        apiClient.joinGame(apikey, gameId, cb)

    createNewGame: function(apikey, cb) {
        request.post(API.url + API.endpoints.games + "?apikey=" + apikey, { //creating game
            body: {
                cartridgeid: config.get("app.game.cartdrigename")
            json: true
        }, (err, resp, body) => {
            cb(null, body)    

There you see two different ways to handle this behavior. The first method actually uses the apiClient class, which again, wraps the interactions with the GameEngine into yet another layer of abstraction.

The second method though performs the action directly by sending a POST request to the correct URL with the right payload. Nothing fancy is done afterwards; we’re just sending the body of the response back to the UI logic.

Note: If you’re interested in the full version of the source code for this client, you can check it out here.

Final Words

This is it for the text-based client for our text adventure. I covered:

  • How to structure a client application;
  • How I used Blessed as the core tech for creating the presentation layer;
  • How to structure the interaction with the back-end services from a complex client;
  • And hopefully, with the full repository available.

And while the UI might not look exactly like the original version did, it does fulfill its purpose. Hopefully, this article gave you an idea of how to architect such an endeavor and you were inclined to try it for yourself in the future. Blessed is definitely a very powerful tool, but you’ll have to have patience with it while learning how to use it and how to navigate through their docs.

In the next and final part, I’ll cover how I added the chat server both on the back-end as well as for this text client.

See you on the next one!

Smashing Editorial
(dm, yk, il)

Source: Smashing Magazine, Writing A Multiplayer Text Adventure Engine In Node.js: Creating A Text-Based Client For The Server (Part 3)