The Simplest Ways to Handle HTML Includes

It’s extremely surprising to me that HTML has never had any way to include other HTML files within it. Nor does there seem to be anything on the horizon that addresses it. I’m talking about straight up includes, like taking a chunk of HTML and plopping it right into another. For example the use case for much of the entire internet, an included header and footer for all pages:

...
<body> <include src="./header.html"></include> Content <include src="./footer.html"></include>
</body>
...

That’s not real, by the way. I just wish it was.

People have been looking to other languages to solve this problem for them forever. It’s HTML preprocessing, in a sense. Long before we were preprocessing our CSS, we were using tools to manipulate our HTML. And we still are, because the idea of includes is useful on pretty much every website in the world.

Use PHP

Can you use PHP instead?

...
<body> <?php include "./header.html" ?> Content <?php include "./footer.html" ?>
</body>
...

This will perform the include at the server level, making the request for it happen at the file system level on the server, so it should be far quicker than a client-side solution.

Use Gulp

What’s even faster than a server-side include? If the include is preprocessed before it’s even on the server. Gulp has a variety of processors that can do this. One is gulp-file-include.

That would look like this:

...
<body> @@include('./header.html') Content @@include('./footer.html')
</body>
...

And you’d process it like:

var fileinclude = require('gulp-file-include'), gulp = require('gulp'); gulp.task('fileinclude', function() { gulp.src(['index.html']) .pipe(fileinclude({ prefix: '@@', basepath: '@file' })) .pipe(gulp.dest('./'));
});

Looks like this particular plugin has fancy features where you can pass in variables to the includes, making it possible to make little data-driven components.

Use Grunt

This is what the grunt-bake plugin does. You’d configure Grunt to process your HTML:

grunt.initConfig({ bake: { your_target: { files: { "dist/index.html": "app/index.html", } } }
});

Then your HTML can use this special syntax for includes:

...
<body> <!--(bake header.html)--> Content <!--(bake footer.html)-->
</body>
...

Use Handlebars

Handlebars has partials.

You register them:

Handlebars.registerPartial('myPartial', '{{name}}')

Then use them:

{{> myPartial }}

There is also fancy features of this that allow for evaluation and passing data. You’ll still need a processor to run it, probably something like gulp-handlebars.

Speaking of templating languages which make use of curly braces… Mustache has them, too.

Use Pug

Pug is an HTML preprocessor that has a whole new syntax for HTML that is a bit more terse. It’s got includes though.

...
body include ./header.html" p Content include ./footer.html" ...

Then you run it with something like gulp-pug.

Use Nunjucks

I love me some Nunjucks! Nunjucks has includes. You’d do it like this:

...
<body> {% include "./header.html" %} Content {% include "./footer.html" %}
</body>
...

If you put that in a file called index.njk, you could process it with a simple Node script into index.html like this:

const nunjucks = require("nunjucks");
const fs = require("fs"); fs.writeFile("index.html", nunjucks.render("index.njk"), function(err, data) { if (err) console.log(err); console.log("Compiled the Nunjucks, captain.");
});

Or process it with something like gulp-nunjucks.

11ty has Nunjucks built-in, along with many of the other mentioned so far. Might be good for you if you’re actually building a little site.

Use Ajax

Say you had…

<body> <header></header> Content. <footer></footer> </body>

You could fetch the contents for the header and footer from respective files and dump the contents in.

fetch("./header.html") .then(response => { return response.text() }) .then(data => { document.querySelector("header").innerHTML = data; }); fetch("./footer.html") .then(response => { return response.text() }) .then(data => { document.querySelector("footer").innerHTML = data; });

Speaking of JavaScript… If you’re building your site using a JavaScript framework of just about any kind, building through components is kind of the main deal there and breaking parts you want to include in other files should be no problem. Some kind of import Header from "./header.js"; and <Header /> is the territory you’d be in in React land.

Use iframes

You could do this:

<body>  Content.  </body>

But the content in those iframes does not share the same DOM, so it’s a bit weird, not to mention slow and awkward to style (since iframes don’t know the heights of their contents).

Scott Jehl documented a cool idea though: You can have the iframe inject the content of itself onto the parent page then remove itself.

<body>  Content.  </body>

Use Jekyll

Jekyll is a Ruby-based static site generator with includes. You keep your includes in the /_includes/ folder, then:

<body> {% include header.html %} Content. {% include footer.html %}
</body>

Jekyll is a big one, so I’m calling it out here, but there are a ton of static site generators and I’d wager any of them can do includes.

Use Sergey

OK, I’ll call out one more SSG because it’s new and super focused. Sergey has a web components style format:

<body> <sergey-import src="header" /> Content. <sergey-import src="footer" />
</body>

You’d name the files header.html and footer.html and put them in /includes/ and then it’ll make a build with the includes processed when you run the npm script it has you do.

Use Apache SSI

Apache, a super duper common web server, can do includes. You do it like this:

<body> <!--#include file="./header.html" --> Content <!--#include file="./footer.html" --> </body>

But you need the right Apache configuration to allow stuff. I tried my best to get a working demo going but didn’t have much luck.

I tried using .htaccess within a folder on an Apache server and flipping on what I thought was the right stuff:

Options +Includes AddType text/html .html
AddOutputFilter INCLUDES .html

I’m sure there is some way to get it working though, and if you do, it’s kinda neat that it needs zero other dependencies.

Use CodeKit

Mac only, but CodeKit has a special language called Kit it processes where 90% of the point of it is HTML includes. It uses special HTML comments:

...
<body> <!-- @import "./header.html" --> Content <!-- @import "./footer.html" -->
</body>
...

Use Dreamweaver

Lol jk. But it really is a thing. DWTs, baby.

Holy Crap

That’s a lot of ways, isn’t it?

Like I said at the top, it’s very surprising to me that HTML itself hasn’t addressed this directly. Not that I think it would be a great idea for performance to have <include> statements that trigger network requests all over our code, but it seems in-line with the platform. Using ES6 imports directly without bundling isn’t a great idea always either, but we have them. @importing CSS within CSS isn’t a great idea always, but we have it. If the platform had a native syntax, perhaps other tooling would key off that, much like JavaScript bundlers support the ES6 import format.

The post The Simplest Ways to Handle HTML Includes appeared first on CSS-Tricks.

The Wonders Of May (2019 Wallpapers Edition)

The Wonders Of May (2019 Wallpapers Edition)

The Wonders Of May (2019 Wallpapers Edition)

Cosima Mielke

We always try our best to challenge your creativity and get you out of your comfort zone. A great occasion to do so is our monthly wallpapers challenge which has been going on for nine years already. It’s an opportunity to let your creative ideas run free and try something new, to indulge in a little project just for fun. Whatever technique you fancy, whatever story you want to tell with your wallpaper, the submissions to this challenge make for a unique bouquet of community artworks each month anew. Artworks that adorn desktops and, who knows, maybe even spark new ideas.

In this post, you’ll find wallpapers for May 2019, created with love by designers and artists from across the globe. The wallpapers all come in versions with and without a calendar and can be downloaded for free. At the end of this post, we also collected some May favorites from past years’ wallpapers editions that are too good to gather dust somewhere down in the archives.

Now before you decide on your favorite this month, we want to say thank-you to everyone who shared their artworks with us. And, well, if you’re feeling inspired, did you know that your work could get featured in one of our upcoming wallpapers posts, too? We’re always looking for fresh talent, so don’t be shy, join in. 😉

Further Reading on SmashingMag:

April Showers Bring Magnolia Flowers

“April and May are usually when everything starts to bloom, especially the magnolia trees. I live in an area where there are many and when the wind blows, the petals make it look like snow is falling.” — Designed by Sarah Masucci from the United States.

Drawing of Magnolia petals dancing in the air.

The Wriggling Glory of River Uvac

“Did you know that there are around 65 pairs of griffon vultures in Serbia? And did you know that one of their natural habitats is located at the river Uvac canyon? Nested between Zlatibor and Zlatar mountains, the wriggling flow of river Uvac is one of the most recognizable marks of Western Serbia and one of the most beautiful natural scenes in the country. And yes, May is just the perfect time to visit and enjoy its glory.” — Designed by PopArt Studio from Serbia.

Photo collage of a main enjoying the view over the river Uvac and its canyon.

Floral Impression

“My main inspiration behind this were the blooming flowers in May. My mother collects blue and white Japanese china which was the pot inspiration. The blues and pinks together are what I find to be one of the most complimentary color palettes.” — Designed by Olivia Osborne from Pennsylvania.

Floral Impression

Lookout At Sea

“I wanted to create something fun and happy for the month of May. It’s a simple concept, but May is typically the time to adventure out into the world and enjoy the best of Spring.” — Designed by Alexander Jubinski from the United States.

Illustration of a tiny island in the sea which houses a lighthouse and a small house.

Happy Birthday To Papú!

“May is the month of celebration! We are happy to share with you the Papú’s birthday.” — Designed by Veronica Valenzuela from Spain.

Illustration of two cats with balloons, a birthday cake, garlands, and a Happy Birthday sign.

May Mountains

Designed by Harley LeBlanc from the United States.

Abstract illustration of pink mountains with the sun rising.

Cool As An Octopus

“A fear I need to conquer inspired this wallpaper design. I never really liked the ocean because of how much we don’t know about it or anything that lives in it. However, I have decided to try and focus on the beautiful parts of this great unknown by choosing an octopus.” — Designed by Alexandra Covaleski from the United States.

Cool As An Octopus

Stranded

Designed by Ricardo Gimenes from Sweden.

Illustration of the Smashing Cat’s rocket which has landed on the moon and seems to have technical difficulties.

Sun’s Out, Tongues Out

“May reminds me of long car rides while the cool breeze whips through the open windows. What better companion to have than a big friendly dog? Cool breeze, warm sun, and a furry friend.” — Designed by Samantha Strausser from the United States.

Drawing of a Saint Bernard dog sticking its head out of the car window, enjoying the ride.

Hello Spring!

“I was at a local bike shop the other day, and I saw one of the vintage bikes. I loved the shape of it. I also was inspired by May flowers.” — Designed by Olivia Bartoli from the United States.

Illustration of a pennyfarthing decorated with red flowers.

Oldies But Goodies

Whimsical, adventurous, delicate — the May wallpapers which reached us in the past few years are as different as the artists who created them. Here are some of our favorites from the past. Which one is yours? (Please note that these designs come from our archives, and, thus, don’t include a calendar.)

Lake Deck

“I wanted to make a big painterly vista with some mountains and a deck and such.” — Designed by Mike Healy from Australia.

Illustration of a beautiful lake landscape as seen through the open flap of a roof top tent.

It’s Finally May, My Deer

“After going through a super long winter, I was inspired to create this whimsical wallpaper because I wanted to highlight the beauty of nature and how I envision it to be during the warmer seasons that have yet to come.” — Designed by Michaela Schmidt from Maryland.

Illustration of a pair of deer antlers decorated with colorful flowers.

All Is Possible In May

“Edwin Way Teale once said that ‘[t]he world’s favorite season is the spring. All things seem possible in May.’ Now that the entire nature is clothed with grass and branches full of blossoms that will grow into fruit, we cannot help going out and enjoying every scent, every sound, every joyful movement of nature’s creatures. Make this May the best so far!” — Designed by PopArt Studio from Serbia.

Illustration of a couple having a picknick.

Spring Gracefulness

“We don’t usually count the breaths we take, but observing nature in May, we can’t count our breaths being taken away.” — Designed by Ana Masnikosa from Belgrade, Serbia.

Abstract illustration of a swan.

Cruel Life

Designed by Elise Vanoorbeek (Doud Design) from Belgium.

Illustration showing three kids. Two kids are happily eating ice-cream, while the other kid is sad because it dropped his ice-cream. The text on the wallpaper reads ‘Sometimes life is cruel’.

Stone Dahlias

Designed by Rachel Hines from the United States.

Watercolor illustration of pastel-colored stones with stone dahlias growing on top of them.

Field Wild Flowers

“Springtime festival celebrated with May blossoms.” — Designed by Richard George Davis from South Africa.

A photo of a wild flower field.

Enjoy May!

“Springtime, especially Maytime is my favorite time of the year. And I like popsicles — so it’s obvious isn’t it?” — Designed by Steffen Weiß from Germany.

The wallpaper reads ‘Enjoy May’. The word May is made up of popsicles.

Birds Of May

“A little-known ‘holiday’ on May 4th known as ‘Bird Day’. It is the first holiday in the United States celebrating birds. Hurray for birds!” — Designed by Clarity Creative Group from Orlando, FL.

Illustration of four flying birds.

Always Seek Knowledge

“‘As knowledge increases, wonder deepens.’ (Charles Morgan) So I tried to create an illustration based on this.” — Designed by Bisakha Datta from India.

Always Seek Knowledge

Magical Sunset

“I designed Magical Sunset as a friendly reminder to take a moment and enjoy life around you. Each sunset and sunrise brings a new day for greatness and a little magic.” — Designed by Carolyn Warcup from the United States.

Illustration of a reading woman sitting on top of a ladder in the light of a street lamp.

Mental Health Awareness Day

Designed by Kay Karremans from Belgium.

Cartoon illustration of a brain.

Game Boy

Designed by Sander Geenen from Belgium.

Illustration of a vintage handheld Game Boy.

Join In Next Month!

Please note that 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 throughout 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.

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

5 Signs That Web Design Is Reaching Its Own Industrial Age

The Internet as a concept, and as a community, is much like a teenager: it’s struggling to establish its identity, everyone is trying to tell it what to do, and it tends to lash out at both people who deserve it as well as those who don’t. It does so at random, and you’re not its real dad, anyway.

The practice of designing websites, however, has gone right past the teenage years and blown past the whole human-life-span metaphor entirely. Web design is, in my opinion, reaching an industrial age, of sorts. You know, the era of smokestacks and Charles Dickens’ really depressing novels.

Let’s see how:

Increased DIY Capability

The sewing machine was invented in 1755, about five years before the “official beginning” of the industrial age. This machine, and others like it, heralded the beginning of that age and the massive machines that would come after, but they also drastically expanded the production capabilities of individuals working at home, or in their place of business.

It started with software like FrontPage and Dreamweaver, and now we’ve got Squarespace, Wix, Weebly, Duda, Webflow, and a host of other options. They’re all designed to enhance the output of the individual, the hobbyist, the business owner, and the freelancing professional. Work that once might have taken a very long time for one person, or a reasonable amount of time for ten people, is all being done by one person, in a lot less time.

And if you’re a purist, you can always sew the buttons onto your web page by hand.

Increased Automation At The Professional-Level

Think of the massive looms in old factories. Now it’s not particularly easy to automate creative visual work, as such. Most of the automation in web design is done at the coding stage, in both front and back end. But even with such simple tools as Symbols in Sketch or Affinity Designer can drastically reduce the work required to produce a large number of designs.

Or at least something like a large number of buttons. It’s not a perfect analogy to the factories of old, but the tools we have are making it consistently easier to produce designs of consistent quality, even if they also have pretty uh… “consistent” layouts and aesthetic styles. This sort of drastically increased output is the very definition of industry.

Expansion Of The Digital Middle Class

Increased DIY capability and automation in the industrial age led to a dramatic expansion in what people could afford. The increased amount of work in general meant that more people could afford that stuff, and thus, the middle class was born.

The same thing is happening in web design. For the hobbyist or professional building sites on the cheap, shared hosting can cost as little as a few dollars a month, and code editors are free. For less code-focused hobbyists and business owners alike, code-free website builders are attractive and largely affordable options, too. Plenty of platforms offer a straight-up free plan.

Getting a web presence of some kind has literally never been easier, and it’s going to keep getting easier.

Outsourcing And Subcontracting

Then, of course, there’s outsourcing and sub-contracting. These come in two major forms: software as a service, and labor. SaaS in particular has become exceedingly popular as a way to build a product that constantly pays for itself, leaving you to focus on maintenance, and improvements. The train engineers of old wish they could have worked on their trains while they were still running.

While few websites are, I think, built by orphans trapped in smoke-filled factories, we should not ignore the fact that there is a lot of cheap labor out there. And you know what? A lot of them are actually really good, and are only cheap because of the economic disparity between nations. This actually leads me to my next point…

Poor Enforcement Of Industry Standards

One of the downsides of industrial ages as they happen all over the world is this: the constant push for progress sometimes leaves much to be desired in the way we treat our fellow humans. Of course, this isn’t happening to web designers in a bubble. The “gig economy” is often used as an excuse not to provide benefits for employees. Cheap labor is often taken advantage of in the worst ways. Overworking people to near-death is accomplished not with whips, but with Instagram and Twitter feeds praising the eighty-hour work week.

And the actual standards meant to ensure the quality of the product are often ignored. The W3C does a lot of good work, but they don’t actually have the power to enforce HTML validation. Well… that’s probably for the best, all things considered, but as we’ve seen, governments are also poorly equipped to provide QA for the Internet as a whole.

However, I should note that I greatly appreciate some of the government-led work done in the field of accessibility, particularly in countries that require WCAG compliance.

Fear Of Obsolescence

The proliferation of industry created a lot of jobs, and killed a lot of others. Design, however, is still a creative discipline, and thus there will always be room for good designers. Even so, automation and code-free design tools have people worried, and I can understand why. That said, lots of people will actually hire you to use Wix for them, so… shrug.

People outsourcing relatively easy tasks might save us, yet.

It’s Not All Doom And Gloom…

We call hand-crafted websites… well… that. Sometimes “bespoke”. Perhaps a better word would be “artisanal”, and we should just get used to being hipsters. I’m only mostly kidding.

In every industrial age we’ve witnessed, things got bad, and then they got better. We haven’t gotten rid of all the smoke stacks yet, but the world is in most ways a much better place than it was, and the Internet is developing faster than the rest of the world. It may be an industrial age now, but imagine what it will be like when they invent computers.

Wait…

 

Featured image via Unsplash.

Add Realistic Chalk and Sketch Lettering Effects with Sketch’it – only $5!

Source
p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

Looking Back At SmashingConf San Francisco 2019

Looking Back At SmashingConf San Francisco 2019

Looking Back At SmashingConf San Francisco 2019

Rachel Andrew

This year, SmashingConf took place at the Fort Mason Center which has superb views of the Bay and Golden Gate Bridge. The weather was very kind to us making it a very pleasant location to spend a few days in.

As always with any Smashing Conference, there were plenty of surprises! We had icecream and cookies, our amazing DJ Tobi Lessnow kept everyone well entertained between talks, and Vitaly opened the conference with just the right amount of balloons!

Conference attendees playing with colored balloons
Balloons, anyone? (Image credit: Marc Thiele) (Large preview)

The videos are now posted, so you can see exactly what our speakers got up to, most of them presenting slides-free, with livecoded sessions.

Conference Videos (Day One)

Chris Coyier and Brad Frost sitting at a desk on stage talking
Chris Coyier interviews Brad Frost (Image credit: Marc Thiele) (Large preview)

Conference Videos (Day Two)

Katie Sylor-Miller at a desk on stage with a laptop
Katie Sylor-Miller explaining Git (Image credit: Drew McLellan) (Large preview)

Our attendees collaborated on a Google Doc for both conference days. These documents are a treasure trove of information and links from our speakers.

  • Collaborative Doc (Day 1)
    Notes for talks by Brad Frost, Sara Soueidan, Anna Migas, Darin Senneff, Steve Schoger, Chris Coyier, Jennifer Brook and David P. Simon.
  • Collaborative Doc (Day 2)
    Notes for talks by Miriam Suzanne, Katie Sylor-Miller, Brendan Dawes, Jeremy Wagner, Jason Pamental and Jen Simmons.

In between the scheduled sessions, we had some great lunch sessions on both days from our friends at Deque, Netlify, and Medium.

Photo of DJ Tobi Lessnow on stage with the crowd watching
DJ Tobi Lessnow hard at work (Image credit: Marc Thiele) (Large preview)

Workshops

Workshops are a great way to spend a day really thinking about a subject. We ran workshops on Monday (the day before) and on Thursday (the day after the conference); they were all sold out, and the rooms were packed! I got to demo subgrid in my workshop which had just appeared in an early build of Firefox the day previously, so they were some of the first people outside of Mozilla to get to see that working.

Monday

  • “How To Translate Wireframes Into Accessible HTML/CSS,” Deque Team (free workshop)
  • “Accessible UI Patterns,” Sara Soueidan
  • “Next Steps With CSS Layout,” Rachel Andrew
  • “New Front-end Adventures, 2019 Edition,” Vitaly Friedman
Sara Soueidan leading a workshop
Sara Soueidan running her accessible UI patterns workshop (Image credit: Marc Thiele) (Large preview)

Thursday

  • “The Design System Process,” Brad Frost
  • “Git To The Next Level,” Katie Sylor-Miller
  • “Advanced CSS & Sass For Modern Applications,” Miriam Suzanne
  • “Smart Responsive UX Design Patterns,” Vitaly Friedman

Side Events

We always want to offer more than the conference, and try to arrange a bunch of side events which offer something for everyone.

Jam Session

On Monday, before the conference began, we had a Jam Session, organized by Mozilla and Shopify and held at the Mozilla offices. In addition to drinks and snacks, there were several micro-talks including:

  • “Creative Design With CSS Shapes And clip-path,” Mandy Michael
  • “Building Accessible Experiences,” Tiffany Tse
  • “The Power Of Code–Based Design,” Marcin Treder
  • “Axe-Pro: A New Kind Of Accessibility Tool,” April Ellsey
  • “Scroll Up! Scroll Up! A Tale Of Animating Over 10,000 Data Points,” Becky Rush
  • “What’s New At Mozilla,” Ali Spivak

Graffiti Walk

Also on Monday, we got together for a graffiti walk led by Scott Whitehead. A group of attendees spent time together exploring the street art of the Clarion Alley Art Street.

The Smashing Run Club

At Smashing SF 2018, Josh Clark suggested a morning run, which I helped organize. I thought we should continue the tradition this year and we had two lovely runs on both conference days out towards the Golden Gate Bridge. It has to be one of the most scenic locations possible for a conference run. It really is a great way to start a day of sitting and learning, by stretching your legs and getting some fresh air.

Conference Party

I was surprised to see so many Wednesday morning conference runners, as on Tuesday night we had a party sponsored by Speedcurve. There were drinks, mediterranean food, and the venue was filled with old-school arcade games!

The Photo Walk

After the final day of the conference, some attendees went off on a photo walk, to enjoy a pleasant San Francisco evening. If you have any photos from that we would love to see them — drop a note in the comments.

There are a few other places you can find conference resources, photos and feedback. If you have written a blog post, posted photos or anything else, add a link in the comments.

Smashing cat stickers on a table
Stickers! (Image credit: Marc Thiele) (Large preview)

Coming Up Next: SmashingConf Toronto

We are going to catch our breath and then we will be straight back into getting ready for our next SmashingConf in Toronto. We still have only a few tickets left, so be quick if you don’t want to miss out.

Note: Tickets to SmashingConf SF were quickly sold out. If you are keen to experience Smashing in San Francisco in 2020, tickets for that event are already on sale with super early-bird pricing.

Follow us on Instagram and Twitter for live updates when any Smashing Conference is ongoing — we always try and share some of the buzz and information with our friends around the world.

https://platform.twitter.com/widgets.js

Smashing Editorial (il)
Perceived Velocity through Version Numbers

HTML5 and CSS3 were big. So big that they were buzzwords that actually meant something and were a massive success story in pushing web technology forward. JavaScript names their big releases now too: ES6, ES7, ES8… and it seems like it will keep going that way.

But HTML and CSS are done with that game. Shortly after the whole HTML5/CSS3 thing, the message was that there will be no HTML6/CSS4. There are reasons for that, like perhaps it’s healthier for CSS modules to evolve independently of some global versioning number.

That said… as Dave says:

… the lull in excitement since those days is palpable….

People aren’t equally excited about the big three languages of the web.

I’m on a bit of a quest to understand why these three technologies built to work together are so unequally yoked in popularity and their communities polarized from one another. One end of the spectrum experiences a boom while the other experiences a bust. The rising tide does not lift all boats.

Surely a major version number release for HTML and CSS could spark a ton of fresh enthusiasm.

I’ll help. HTML6 could have HTML imports for web components, <include>, and a multi-select. CSS4 gets container queries, subgrid, standardized form control styling, and transitions to auto dimensions.

Direct Link to ArticlePermalink

The post Perceived Velocity through Version Numbers appeared first on CSS-Tricks.

3 Essential Design Trends, May 2019

Sometimes designs are of an acquired taste. That’s our theme for this month.

Each of the projects and trends featured here are things that you’ll probably either love…or hate. But wait to judge these projects until you navigate through them; most of them seem to grow on you the more you dive into the content. Here’s what’s trending in design this month:

Chaos by Design

Have you ever looked at a design and wondered “what were they thinking?”

But then … “that is actually pretty nice.”

It seems like there are plenty of designs out there right now that feature a structure of chaos. These projects are identifiable by an aesthetic that seems to be all over the place, but the more you dig into it, the more it seems to come together.

Common themes include:

  • Lack of an obvious grid
  • Lots of motion or animation across multiple elements
  • Website elements with the same visual weight
  • “Too many” fonts or colors
  • Oversized elements that make you think about content
  • “Trendy” word breaks without hyphenation
  • Peeking elements from the edges of the canvas

If these things sound like they could make a mess out of the design, you are totally right. But what’s happening with these projects – and the super talented design teams behind them – is that they break all the rules and work.

You will want to keep scrolling through these designs to see what comes next. Each of the examples below incorporates some of these themes and they are stunning.

Oversized Lettering

Big, bold typography has been a trend in website design for some time (we’ve explored that here on multiple occasions.) But there’s been a common theme until now: Most oversized type has been of the sans serif variety.

Now the trend is shifting to an even bolder display above the scroll: Oversized lettering and script fonts.

Each of the examples below uses this trend in a different way:

Kota uses a subtle gradient-color animation in a minimal style design. The letters KOTA are the brand of the website and have a memorable design. While the main logo of the site uses a simple square mark with a sans serif, the funky lettering style is carried through the design in the form of call to action links/buttons.

Feral also features its name in the center of the screen with a handwriting style font, but the bright yellow letters are on top of a dark image and behind a simple tagline for the company. The rest of the design is brighter and more minimal, but hints of the funky font carry through in surprising details.

Alt is a little less big than the other featured trending designs, but it is just as bold. What’s nice about the handwriting-style font here is that it is sleek and has a retro feel. As a center-screen element, it draws the eye in among multiple smaller photos and helps create a sense of cohesion among elements. The font and bright blue color combination do a great job of setting the mood for this website design. (Pay attention to the animation as well. The words don’t move while the image pop around it, some behind and some in front.)

The common theme among all three projects is that this style of typography works best with a single word or short phrase. This style of type can be a challenge in terms of readability, so sticking to a simple use is the best option.

Poster-Style Hero Images

Creating a poster-style hero image or homepage screen might be the least controversial trend in the roundup this month, but it can be equally challenging when it comes to design. With multiple layered elements and bold elements, getting the visuals to collapse (or expand) to different responsive viewports can take some work.

There are so many different ways to create a design that follows this trend. The commonality is that the first screen is an immersive visual experience. It’s not a about how much to read or three places to click; it’s about setting the scene for interactions to come.

What often makes this design style work is a combination of amazing imagery – each of the examples below start with stunning images – impactful text and enough of a curiosity tease to get users to explore the design more. (It’s also interesting that all three examples are from design studios; that’s where many envelope-pushing trends show up first.)

Deep Blue does this with an amazing visual. You might not know exactly what the website is about at first glance, but it’s so pretty that you’ll probably scroll to learn more. If you do, the design has done its job.

Chaptr Studio uses a striking image in a different way. It grabs your attention with a tiny, animated cursor that expands on clickable elements. Users hardly have to try to understand that there’s much more to this design.

Alber Graphics tugs at your curiosity with a stunning image and visual theme that is reminiscent of “Through the Looking Glass.” The visual presentation is so strong that users want to know what’s next; can you feel yourself wanting to engage with the CTA just to see how they respond?

Conclusion

How many of this month’s trends could you see as part of future design projects?

Working with super trendy elements, especially ones that break common design rules or contrast with principles of design theory, can be a challenge. But if you get it right, there’s a huge upside. That’s what you get with each of the projects above; these risky design concepts are well worth the time and are a lot of fun to explore.

Add Realistic Chalk and Sketch Lettering Effects with Sketch’it – only $5!

Source
p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

A Designer’s Guide To Better Decisions

A Designer’s Guide To Better Decisions

A Designer’s Guide To Better Decisions

Eric Olive

Nearly everyone has experienced frustration while using a website, mobile app, or web application. In these moments, we might wonder “What were they thinking?” followed by “They sure were not thinking about making this easy for me.” One reason we encounter such frustrating moments is that the process of making sound and user-friendly decisions is difficult.

In this article, we’ll identify four decision-related traps that impede good design and offer techniques for avoiding these traps. These decision traps are based on research conducted by psychologists, neuroscientists, molecular biologists, and behavioral economists including several cited in this article.

Too many design decisions occur in isolation, are based on gut feel, or are not carefully examined. The web offers many examples of poor design decisions. For instance, let’s take a look at the example below.

A field in a form asking users to enter the place of birth. And Hover text that says: 'Please enter the place of birth of your parent.'
On the left: Are they asking for city, state, or country? On the right: This tooltip does not answer the user’s question. (Large preview)

At first glance, it seems quite straightforward: type the place of birth in the text field. A moment’s reflection, however, raises a question. Should we type the country, state, or city? It’s not clear. Clicking the question mark icon displays the help text shown below, to the right. The problem? The text does not answer the question; it simply restates the original request about entering the place of birth.

The design shown above violates a basic tenet of user experience (UX) immortalized by the title of Steven Krug’s famous book Don’t Make Me Think. Sure, it’s an amusing title, but he’s serious. The entire field of user experience is based on the idea of reducing the user’s cognitive load:

“Just like computers, human brains have a limited amount of processing power. When the amount of information coming in exceeds our ability to handle it, our performance suffers.”

Kathryn Whitenton

In other words, when a design requires users to guess or think too hard about something as simple as one text entry, users will often make mistakes (costing your organization time and money) or abandon the task altogether.

Lightening the user’s cognitive load means increasing our own cognitive load as designers. We do have to think, hard and carefully. Essential to this effort is learning how to make good design decisions.

There are four common decision traps that we often fall into. I’ll explain how you can avoid them.

  1. Availability Heuristic
  2. Focalism Bias
  3. Optimism Bias
  4. Overconfidence Bias

1. Availability Heuristic

A heuristic is a mental shortcut that helps us make decisions quickly. These mental shortcuts are essential in certain situations. For example, if a car veers into your lane, you must act quickly; you don’t have time to review several options.

Unfortunately, heuristics become a flaw when making decisions in situations where many factors and participants must be considered. One such flaw is the availability heuristic, which involves an incomplete examination of current and past information.

A particularly distressing example of the availability heuristic in the design space is the software on the Boeing 737 Max. As of this writing, it appears that this software contributed to the tragedy of the downed airplanes. People around the world have asked how to prevent such tragedies in the future.

Part of the answer lies in avoiding quick fixes. Airbus, Boeing’s chief competitor, had refitted their A320 planes with larger engines. Boeing felt pressured to do the same leading to a variety of changes:

“The bigger engines altered the aerodynamics of the plane, making it more likely to pitch up in some circumstances.”

To compensate, Boeing added new software to the 737 Max:

This software “would automatically push the nose down if it sensed the plane pointing up at a dangerous angle. The goal was to avoid a stall. Because the system was supposed to work in the background, Boeing believed it didn’t need to brief pilots on it, and regulators agreed. Pilots weren’t required to train in simulators.”

The obvious and horrifying conclusion is that Boeing engineers and designers were placed under immense pressure to re-design the 737 Max at record speed resulting in a series of misjudgments. Less obvious, but equally troubling, is the likely role of the availability heuristic in these tragedies.

In short, the information used to make critical design decisions was not sufficient and resulted in tragedy.

Small red circle within a much larger blue circle
The availability heuristic limits our perspective (Large preview)

Solution

One solution is for designers to identify their area of competence. Within this sphere their intuitions are likely to serve them well, explains author Rolf Dobelli in The Art of Thinking Clearly. For example, UX designers should feel comfortable making decisions about layout and interaction design issues like flow, navigation, and how much information to present at one time.

When designers face a decision outside their circle of competence, it’s worth taking time to apply hard, slow, rational thinking. For example, when designing cockpit software for jets, designers would be well advised to work closely with engineers and pilots to ensure that everything in the proposed user interface (UI) is precise, accurate, and provides the information pilots need when they need it.

We are all subject to the availability heuristic. Designers must strive to mitigate this heuristic by consulting a variety of subject matter experts (SMEs), not simply the programmers and engineers on their immediate teams. The downside risk is simply too high.

2. Focalism Bias

The availability heuristic hinders our ability to assess current and past information. The focalism bias concerns our ability to look forward. It refers to the inclination to concentrate on a single point when considering the future. As Harvard psychologist Daniel Gilbert explains in his book Stumbling on Happiness:

“It is difficult to escape the focus of our own attention — difficult to consider what it is we may not be considering.”

Camera lens showing a nature scene in focus
The focalism bias restricts our view of the future. (Large preview)

For example, while my colleagues and I were conducting UX research for a U.S. government agency, we discovered that caseworkers could not access information essential to processing applications for medical assistance.

As shown in the diagram below, these caseworkers literally had to stop in the middle of the application process in order to request critical information from another division. Typically, caseworkers had to wait 24 to 48 hours to receive this information.

Diagram listing many steps before re-design and fewer steps after re-design
The focalism bias led to a delay, the opposite of the desired results. Our re-design resolved the issue. (Large preview)

Caseworkers found this delay stressful because it made it more difficult to meet a federal law requiring all applications to be processed within 10 days of receipt.

How did this happen? One reason, surprisingly, was the emphasis on deadlines. Through our observation and interviews, we learned that the system had been rushed into production to meet a project deadline (all too common) and to give caseworkers a way to process applications more efficiently.

The intentions were good, the goals made sense. Unfortunately, the focus on rushing a system into production to supposedly expedite the process had the opposite effect. Designers created a system that delayed the application process.

Solution: Become An Active Problem Seeker

This idea may sound counterintuitive. Why would we look for problems? Don’t we already have enough to deal with? In truth, however, organizations that seek problems, such as Toyota, often demonstrate impressive performance. They’re called high-reliability organizations (HROs). Other examples include the U.S. Navy’s aircraft carriers and air traffic control centers in the U.S., both of which have incredibly low error and failure rates.

As decision expert Michael Roberto of Bryant University explains, leaders of HROs do not wall themselves off from the possibility of failure. On the contrary, they preoccupy themselves with failure. For example, they:

  • Do not simplify explanations.
  • Remain sensitive and attentive to their front-line operations as we did while observing caseworkers.
  • Defer to those who have the local, specialized knowledge as opposed to those who simply have authority in the hierarchy. Again, we relied on the expertise of caseworkers on the ground.
  • Commit to resilience, to the notion that you cannot prevent all small problems. Rather, the goal is to focus on fixing these small problems before they mushroom into large problems.
Man standing on a mountain looking out with binoculars
Actively seeking problems leads to better decisions. (Large preview)

Problems are not the enemy; hidden problems are because these hidden problems become serious threats down the road as we saw in the government agency examples outlined above. In both cases, earlier and additional contextual inquiry (observing users in their natural home or work environments) would likely have identified current problems and possible UI solutions to these problems.

For example, while conducting contextual inquiry for a large Mexican bank, I observed customers trying (and failing) to transfer money to family members who held accounts at different banks. Customers expressed frustration at this limitation because they wanted an easy way to send money to family members, especially those who lived far away.

While living in Mexico, I learned that loaning and giving money to family members is more common in Mexico than in the U.S., Canada, or parts of Western Europe.

Given the deeply rooted Mexican tradition of supporting family members in financial need, I was initially surprised by this banking limitation. Upon reflection, however, I realized that this limitation was simply a hidden problem. When coding the banking web site, the developers were likely focused on security, paramount in all matters financial. They had not considered including a cross-bank transfer feature.

I identified this missing feature by conducting UX Research with banking customers in Mexico. This real-world example shows how critical it is to become an active problem seeker.

3. Optimism Bias

Focusing on a single point or problem impedes our ability to plan and design for the future. An equally troubling challenge is the optimism bias. We tend to imagine the best-case scenario.

“For example, we underrate our chances of getting divorced, being in a car accident, or suffering from cancer. We also expect to live longer than objective measures would warrant, overestimate our success in the job market, and believe that our children will be especially talented.”

Tali Sharot

In design culture, this bias sounds like this:

“Sure, this part of the UI is a bit clunky, but customers will get used to it, and then it won’t be an issue.”

In other words:

“We need to ship the product; we don’t want to deal with the cumbersome interaction.”

As anyone who has conducted a survey or usability test knows, this optimism is misplaced. Users and customers are easily frustrated and often show little patience when products and UIs are hard to use.

I witnessed this bias when designing a web application for financial advisers — 70% of whom were male. The client insisted on using a red font to emphasize certain numbers. Even after I explained that approximately 9% of males are color blind, she refused to change the font color. She reasoned that financial advisers would see the numbers in context. In other words, no problem. When I conducted multiple rounds of usability testing, however, two male advisers struggled to distinguish the numbers in red. They could read those numbers, but the figures did not stand out.

The reason for this type of wishful thinking is our tendency to see the future as a variant of the present. We tend to assume that things will go on more or less as they have. In the case of the financial application, because advisers had not complained before so my client assumed that they would not complain in the future. What she failed to grasp was the significance of changing the font to red.

As author David DiSalvo explains:

“We tend to simulate the future by re-constructing the past, and the re-construction is rarely accurate.”

Solution: The Pre-Mortem Technique

That’s why it’s essential to resist this innate tendency by leveraging techniques like psychologist Gary Klein’s pre-mortem. The idea is to describe a scenario in which the project failed to meet a specific goal such as a revenue target, an increase in the percentage of new purchases, requests for more information, etc.

Here’s how it works. Before committing to a major initiative, the key stakeholder (often an executive) gathers everyone who is slated to participate. She outlines the key objective and explains “what went wrong.” The statement will sound something like this:

“Imagine that we have rolled out a new e-commerce mobile app at a cost of $3 million with a projected revenue of $10 million for the first year. At the end of one year, revenue is $1 million, a huge failure. Please take 20 minutes to write a history of this failure.”

This pre-mortem exercise:

  • Legitimizes doubt by providing a safe space for asking questions and expressing concerns about the decision.
  • Encourages even supporters of the decision to search for threats not previously considered.

An e-commerce mobile app is simply an example. The pre-mortem technique can be applied to nearly any project in any industry because it’s about expanding our perspective in order to identify what could realistically go wrong.

4. Overconfidence Bias

We unconsciously exaggerate our ability to accurately assess the present and predict the future. A study of patients who died in a hospital ICU compared the doctor’s diagnosis to the actual autopsy results. The doctors who were completely confident in their diagnosis were wrong 40% of the time.

When designers fall prey to the optimism bias, they exaggerate their ability to understand how users think. The most common results are information overload and confusing terminology and controls (buttons, checkboxes, sliders, and so on).

For example, while evaluating a client’s tablet-based investment application targeted at lay people, my team and I immediately noticed that:

  • The screen where users would create a risk profile included extraneous information.
  • The phrase “time zone” would likely confuse users. The client intended the term to refer to the customer’s investment time horizon. Yet, “time zone” usually means the time in a country or region, such as the U.K. or South Africa.
  • Plus and minus controls exhibited low affordance meaning that it was hard to tell whether they could be tapped or were simply part of the display.

These observations were supported during a subsequent usability test when participants expressed confusion over these specific points. In short, the designers for this project had overestimated their ability to create an interface that users would understand.

Solution

One solution is to conduct user research as we did with the tablet-based financial application outlined above. If such research is not possible, a second solution is to actively seek case studies beyond your immediate context. For example:

  • If you are designing an investment application, it might make sense to **refer to banking applications** to identify potential design challenges and what is already working well for customers.
  • If you are designing a tablet application to help nurse practitioners make a preliminary diagnosis, **look to other projects that are related** but outside your immediate context. Has your company developed a medical device UI for surgeons or ER doctors? What worked well for users? What did not?

Referring to other projects may sound like a no-brainer. Ask yourself, however, how often a systematic review of previous, related (but not identical) projects occurs within your organization. Remember, we are all subject to overconfidence.

Conclusion

In this piece, we’ve identified four common decision traps and corresponding solutions:

  1. The availability heuristic causes us to ignore potentially important current or past information when making decisions. The solution is to expand our perspective by reaching beyond our circle of competence. For designers, this often means consulting highly technical experts.
  2. Closely related is the focalism bias, our tendency to concentrate on a single point when designing thus overlooking other, equally important factors. The solution is to actively seek problems in order to identify and address hidden problems now before they become even larger difficulties.
  3. The optimism bias refers to our tendency to imagine the best-case scenario. The solution is the pre-mortem technique. In this exercise, we imagine that a design project has gone terribly wrong and discuss why and how this happened. As with active problem seeking, the idea is to identify issues before they occur or get worse.
  4. In the design space, the overconfidence bias refers to exaggerating our ability to understand how users think and design accordingly. The solution is to conduct user research and seek case studies similar to the current design initiative.

The cognitive biases discussed here are not intended to criticize designers (I am one). Rather, they are scientific observations about human nature. While we can’t change our biology, we can remain mindful of this biology and apply the four solutions outlined in this article. In so doing, we will increase the chances of creating better, safer, and more engaging designs.

Resources

Smashing Editorial (ah, yk, il)
Popular Design News of the Week: April 22, 2019 – April 28, 2019

Every week users submit a lot of interesting stuff on our sister site Webdesigner News, highlighting great content from around the web that can be of interest to web designers. 

The best way to keep track of all the great stories and news being posted is simply to check out the Webdesigner News site, however, in case you missed some here’s a quick and useful compilation of the most popular designer news that we curated from the past week.

Note that this is only a very small selection of the links that were posted, so don’t miss out and subscribe to our newsletter and follow the site daily for all the news.

UI Design Inspiration – Apr 2019

 

New Logo and Identity for Nike by You

 

Are You Making these UX Errors?

 

The Ugly Truth Why your Website is Slow

 

Color Designer – Simple Color Palette Generator

 

Top 5 Design Tools for Getting Striking Visual Content

 

What Does Unsplash Cost in 2019?

 

How to Protect the Admin Area of your WordPress Site

 

Nord Design System

 

LinkedIn Redesign UI/UX Concept

 

Tips on Using Colors in UI Design

 

Open-source Illustrations for Every Project You Can Imagine and Create

 

Three – Free Semi Condensed Typeface with Four Weights

 

Accenture Sued Over Website Redesign so Bad it Hertz

 

The Story Behind the Redesigned Game of Thrones Title Sequence

 

Choose the Right Navigation for your Mobile App

 

Two Words that Have Made Millions

 

Instagram Hides like Counts in Leaked Design Prototype

 

Site Design: Museum of Digital Art

 

Greater than Avatars

 

What Creative Visionaries do that Most People Overlook

 

Ikonate: Fully Customisable & Accessible Vector Icons

 

Gangster Grotesk: A Sharp Typeface Free for Personal and Commercial Use

 

Will these UX Trends Stick or Fade Away?

 

The Art of Simplicity in Product Design

 

Want more? No problem! Keep track of top design news from around the web with Webdesigner News.

Add Realistic Chalk and Sketch Lettering Effects with Sketch’it – only $5!

Source
p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

Interviewing for a Technical Position Doesn’t Have to Be Scary

Jacob Schatz (@jakecodes) is a staff engineer over at GitLab and was kind enough to share how he conducts job interviews for technical positions and his thinking process for them. Technical interviews are talked about often and can be a touchy subject for some, so it’s worth noting that this article expresses Jacob’s own opinions and are not necessarily shared by his employer.

Are you an interviewee who is terrified, exhausted, sad, or disappointed? I’d love to change that stigma.

I believe that people can have a great interview experience, and that I can simultaneously find the right candidate. Both things can happen at the same time! After your interview process is over, in a perfect world, regardless of outcome, you should feel good about yourself and the process. You might feel sad that you didn’t get the job or excited to start your new job, but you should understand why in either situation.

At GitLab, I was put in charge of hiring very early on, and as such, I’ve seen thousands of resumes. When I first joined, I was asked to hire and form a team of front-end developers. I was employee #29 (we now have 500+), and I was the first front-end developer, so there was no hiring process for our team. We gradually created a process.

This article is aimed at both the interviewee, and interviewer. For the interviewee, I want you to know what a perfect interview can be like. Interviewing should not be scary or intimidating. This is a guide you can follow to do your part in creating the perfect interview. If you are an interviewer, maybe you have perfected your process. This is my view on how interviews can go in a perfect world. There are all different types of interviews, and this article focuses on interviewing developers of all experience levels. Over the years, I’ve latched on to some great processes, and this article is a behind-the-scenes look at that process for both sides of the candidacy.

Before I begin, it’s important to remember that everyone is human and humans are not perfect. There are no perfect developers. Treat everyone like a regular human being. It’s OK to be amazed at what some people are doing, but not OK to worship others. Talent is both congenital and acquired and you can acquire it too. Your interviewer and you are both imperfect. Interviews should not be focused around perfection. Here’s what interviews should be.

Five things I look for in a candidate

The GitLab Values cover a lot of great points and you should read it. This is loosely based on those.

As an interviewer, I can only focus on so many things at once while being a productive, active listener. But I do have five specific things I am try to focus on:

  1. Does this person have a “good head on their shoulders”?
  2. Is this person technically where they need to be for this role?
  3. Is this person going to be self sufficient in this role?
  4. Does this person communicate well and will they communicate well with the team?
  5. Does this person handle positive and negative feedback well?

There are other things I’m looking for, of course, but these five things are enough to get you the job you want if you’re interviewing with me.

Forget nervousness. I won’t ever hold it against you. I know you may be nervous, and that’s totally fine. There is the rare occasion that nervousness becomes a debilitating factor, and in those cases, I just ask that you reschedule. Just don’t hang up on me!

Recognize there’s going to be bias

We have training on bias at GitLab. One thing I learned from the training is that everyone is biased, whether or not you think you are. At one point, I had the idea of doing blind interviews like they do for some orchestras. We never implemented it (and it would be tough) but that’s why I keep a list of questions and a summary of what I want to cover in each interview. Each interview has a script I can follow. Everything is as repeatable and similar as possible. As the interview progresses, I’ll be able to tell if I can hit the harder questions. Harder questions are not there to disqualify people, but to qualify people. If you get to my hard questions it means you have a ton of experience and knowledge under your belt. It’s really important to know that I must ask trivia questions in some form but I don’t qualify candidates based on trivia questions. It’s about figuring the depth of your JavaScript knowledge and programming in general.

That being said, there is still one trivia question no one has ever gotten right. I’ll just keep asking it, and I am sure some day, someone will get it. Trivia questions are fun, because I am a major JavaScript dork. I just love talking about all the ins and outs of JavaScript. I am looking for people that can be my coding buddy. Hiring people is about finding other people you can work with, not people that will work for you.

https://platform.twitter.com/widgets.js

I want to know you’re technically sound

This may be people’s worst fear. The part of the interview where we ask questions like, “Why are manholes round?” The truth is that some companies may ask the medium-to-hard questions from LeetCode, and some may never ask any technical questions.

What I’m looking for in your skillset

Experience speaks louder than any technical interview question I can ask. For example, if I’m hiring for a front-end engineering role and someone tells me they built their own cool things that we can talk about, then that’s awesome. I still may need to throw some more questions their way after that, or maybe the demo answers all my questions (though unlikely, but possible). But if we can walk through the code of something that you are super proud of, that’s great.

It’s helpful if you can tell me about something that you built for another company where I can see your code, or you can explain it sufficiently enough. What were the challenges? How did you deal with 10,000 comments? How did you deal with mobile? What were some challenges? I’ll give you an example: You built the comment system for GitLab. For the comment system, an interesting challenge was dealing with loading users for the @ drop-down to mentioning other users. It turns out that the JSON payload for that drop-down can get quite large and loading it on page load makes the page load significantly slower. But loading that data on the first @ keypress is also slow because the payload can be more than 10 MB. We want the user to have a seamless experience and not realize the data needs time to load. So, a good way to talk about that experience would be to describe some of the approaches you considered, like:

  1. Load the data when the comment box first appears in the viewport.
  2. Load the data on the user’s first mouseover of the textarea.
  3. Load the data once the user starts scrolling with enough momentum.

That last one isn’t a boring solution, but is something I’ve heard someone say in an interview.

I might ask about algorithms and data structures

Hey interviewers, are you hiring someone for your marketing site? Don’t ask them the hardest algorithms and data structure questions. Yes, algorithms and data structures play a huge part in everything, but it’s more important that the candidate knows about responsive design, and maybe animations, and performance. Since we are talking about performance, they should know about Big O notation. They should know what causes re-paints. Look at Firefox Monitor and compare it to Salesforce. Everything about the Firefox site is much more snappy. Why is it more snappy? Why is the Salesforce site so chunky and slow? Resize them… oy vey! Big O would probably help you explain some parts, but being able to explain the whole picture is important.

Quick aside on Big O notation since I brought it up.

Big O is a way of describing the time your code will run in and/or the memory space your code will take up in a worst case scenario. I think it’s really great to learn, and helps out in every day programming. You can and should learn it, which might take about an hour. After one hour, done or not, you’ll more than likely be prepared for any legitimate Big O question that interviewers would ask.

Big O is not something you need to take a course on. Here are some articles that can explain it to you in under an hour:

OK, back to algorithms and data structures in interviews.

Since there’s a chance these types of questions will come up, it’s worth doing a little homework in advance. There are two typical gold standards when studying for interviews that ask about algorithms and data structures.

There are many other things that are recommended for algorithm and data structure, heavy coding interviews, but rather than memorizing every example in the world (which won’t solve any problems for you), it’s better to learn how to solve these problems.

As I said above, front-end engineers should learn Big O for their health, because it’s good for you, like eating your Wheaties. Interviewers should not ask extensive algorithms and data structure questions unless the job requires extensive knowledge of them. If I was designing a front-end framework, say like Vue, it would be important to optimize a DOM diffing algorithm or at least understand the implementation of the algorithm you are using. But does that mean I would ask seven extra hard questions from a CTCI? No. You are testing for understanding, not for memorization. When people work through these questions (when I ask them), I want to see that they thought through the problem and we worked it out together more than I want to see that they got the right answer. It’s all about figuring out what you will be able to do, as an engineer, when you get the job — not what you memorized yesterday. A person who has knowledge of algorithms is going to be better at implementing them than someone who has to learn them on the job.

Are you hiring someone to build a dependency management system? This person needs to know a lot about algorithms and data structures.

These are two extreme ends of the spectrum, but in my opinion, not everyone needs to know how to write a red-black tree from scratch — but everyone should understand Big O. However, it will dramatically improve your skills as a software developer to learn typical algorithms and data structures.

When I do ask algorithm and data structure questions here are a few I do ask:

  • What is a linked list and can you show me how to implement one with and without an array in JavaScript?
  • What is the difference between BFS and DFS and can you implement one of them?

Getting these wrong will not disqualify anyone. Remember, I don’t use trivia to qualify people.

Do you have a good head on your shoulders?

There are a lot of soft skills I’m looking for as well during the interview. It’s my way of determining whether you have a “good head on your shoulders.”

Pedantically speaking, that means you make good decisions, but it’s much more than that to me. People who have a good head on their shoulders make sound decisions. It’s good to have different opinions than me, but there is a standard of knowledge we should agree on. For example, we should all agree that laying out an entire blog with only absolute positioning is a bad idea. That is not a sound decision.

But I might create a scenario like this to check on those skills:

Let’s go into CodePen and create a static blog homepage. We’ll need a navigation menu, and we’ll need a place for the title and article, and then at the bottom let’s have some comments and a footer.

I’d then talk you through different ways you could create the navigation and the pros and cons to each. For a lot of the front-end developers I hire, I’d like to know that they know some core JavaScript so I might ask them add some small functionality using only vanilla JavaScript.

When a framework does everything for you, you don’t need to do things yourself. I want to know that you get the whole picture.

A “good head on you shoulders” is a fancy way of telling me that you have your crap together. This is not an exhaustive list, but are the types of things that catch my attention:

  • You take care of yourself
  • You speak professionally (this has more of an impact than most people know)
    • Leave out super personal details
    • Answer questions succinctly
    • Take time to think
    • Say, “I don’t know,” when you don’t know
    • Be confident, but not cocky, even if you aren’t
  • You finish what you start
  • You are honest
  • You are able to say no
  • You know what you want and you want to help others get what they want
  • You’ll disagree and even debate, but know when to let something go
  • You are able to effectively communicate in an interview
    • Is this conversation easy or exhausting?
    • Are you fluent in English? Accents are totally OK!
    • Do you grasp the concepts being discussed?
  • You’re a kind person.

On that last point: kindness doesn’t mean you are a pushover. Kindness is a major part of challenging others and giving feedback.

I want to see that you are self-sufficient

It seems obvious now, but I am convinced — after working at GitLab — that self-sufficiency is what interviewers should seek in everyone being hired. Self-sufficiency plays a big part in your role in the company.

For example, to go extreme, think about a GM, who may have the least amount of external direction of anyone on a team. Everyone has responsibilities, but a GM must often be good at many things, including (but not limited to) marketing, sales, and management. All this changes based on the size of the team. Their role may be the most vague. They are very self-sufficient. A senior developer (in my opinion) should be able to take on an entire large piece of functionality and implement it properly.

This is not to say a developer shouldn’t communicate during the process. They should ask questions, and pair with other people to find the best way forward.

Reviewing an interviewee’s code has the opportunity to be boring (in a good way) as we know what to expect from them. We are relying on them to mentor less experienced developers. Junior developers should be self sufficient too, but probably won’t take on large initiatives alone. Junior developers often work great in small chunks. For example, it might be a great thing for a junior developer to take on the smaller tasks that a senior developer has on a larger project. Senior developers can also mentor junior developers and nudge them in the right direction to help them become more self-sufficient, which is a great thing for both parties — and also a great thing for the manager, as they can delegate more work to a senior developer.

If you are a front-end developer and need hand-holding at this point in your career, that is totally 100% OK, and everyone has been there. Or, if you are applying to a lot of places and not getting anywhere, and are extremely frustrated: I suggest that you become a little more self-sufficient before you apply. One way I suggest to become more self-sufficient and nab that job you want: Forget code examples, little shopping cart apps, and their ilk, as they don’t fair well for job interviews. Build something full-fledged for someone and do it for cheap or free. Find a church, synagogue, homeless shelter or someone near you and offer to make them a website.

Just remember that free clients are often the worst clients. It will be worth it when you can say that you’ve done work for a few clients. For bonus points, document your work in a few blog posts. This stuff looks great on resumes and will make you stick out from the rest. I know that anyone can get an easy website through Wix or other site building platforms, but there’s nothing like a wonderful custom-designed website. I think I made around 10 or so websites before I had my first programming job. I could fill a book with crazy stories from those times.

Communication and feedback is key

This is another point that seems obvious, but is hard to do right. Communication is well documented in the GitLab Handbook so I won’t cover it, except to say that I follow GitLab’s values and we are looking for others who desire to follow those values as well. Positive and negative feedback is also well documented in the GitLab Handbooks, so I won’t cover it here.

How I go about the rest of the interview

Because we interview a lot of candidates at GitLab, we follow a common flow so we can repeat it easily. I won’t go into specifics about our interview process, because it’s constantly evolving. But, in general, this is the flow I follow.

Tell me about yourself

You’ll get asked the famous question that goes along the lines of “tell me about yourself,” “tell me what you’ve been doing,” or “tell me about your time at [Company Name].” When I ask this question, I am trying to find the connection between the job you applied for and the jobs you’ve had in the past. It’s good to find the common ground ahead of time.

Like, for example, as an employee of GitLab, if I were personally applying to a FAANG as a front-end engineer, I am sure both GitLab and that company are trying to get page load times to be faster. Maybe I noticed there were 26K event listeners on a page when I first joined GitLab and was able to reduce it down to 0, decrease the loading time by 50%, down to a speed of 200ms. I am sure this would be something relevant to the conversation.

So, as an interviewee, I might say something like this:

“Hi! I am a front-end engineer at GitLab, I’ve been here for 3.5 years and during my tenure I’ve made a ton of huge improvements, some of the areas I loved working on are performance, UX design implementation, and architectural design.

You don’t want to get into tons of details at this point, but it’s good to give the interviewer some facts to work with. It is frustrating when I ask this question and someone goes into a 10-minute detailed account of their entire career.

What made you apply to our company?

The interviewer might ask, “What made you decide to apply to our company?” Hopefully, you are excited to work at this company — otherwise, why bother applying for it?

For some reason or another, this question often sends a candidate into overdrive and they wind up mixing up the name our company. That’s perfectly normal behavior, especially if your company sounds like another company.

What I’m looking for at this point is to see whether you are just looking for a job or that you’re really excited to work with us. We want people who really want to work with us. This is when I can also see if a person knows anything about our company. For example, some people like our values, have read them and want to work at a company with these values. Some people want to solve big problems like the ones we are tackling. Some people have seen talks and read articles from our team and would love to work around smart people like them.

What are your five things?

Lastly, I like to ask if a candidate has any questions for me. This is an important part of the interview, and you should extensively think this through beforehand. Your goal is to make me respond with: “Oooohhh, great question!” On one hand, I am truly trying to answer any questions you have, so don’t be shy. On the other hand, I am also trying to gauge your interest in the job, so something like, “Uh, I dunno,” is usually a big bummer to hear because it signals that maybe you’ve tuned out, or the job is not interesting to you. that’s can leave an undesirable aftertaste.

Look up your interviewers and find out about them. Doing this in advance can be an eye-opening exercise. You might find out about their customer acquisition strategy which could lead to a ton of other interesting questions. If the company is a startup, do they plan on being acquired, or do they want to IPO? When you have a clear, well-thought question, it makes you sound professional, which again, is one of the things I listed as important.

If you can’t think of any questions to ask, then do you really want this job in the first place? If the interviewer has a personal website, go check it out, and if nothing else, you can ask them about the comic book they wrote and posted to their website.

But I’d advise:

  1. Ask the interview questions that you are generally interested about. Think about this before the interview because a really thoughtful question generally improves your candidacy quite a bit.
  2. What are you, the candidate, looking for in a company? What does this person, the interviewer, need to prove to you in order for you to take this job?
  3. Do these people have a good head on their shoulders like you do? It works both ways, you know.
  4. Does this look like a fun job? Do you even want a fun job?
  5. Who would you report to? Did you talk to them? Will you get a chance to during the interview process?
  6. Are you underrepresented? Like, are you replacing someone or filling a new role? How many others will be doing what you’re doing? What signs should other underrepresented people look out for? What signs would show you that this is a good environment for you?

Don’t ask about money or benefits at this point; those things can (and likely should) be covered with a recruiter introduction call before you get to a person like me.

Conclusion

Interviewing, unlike programming, is not an exact science. You’re trying to prove that you are excited about the prospect of working with a company. You want to prove this to the interviewer and yourself. Hopefully, you want a job that is interesting. This guide isn’t a script to follow, but more of a few loose ideas to help you get into the mindset of the interviewer, with a few tips for other interviewers strung in there as well. Maybe I pointed out things you might not have known before.

Just remember that, in theory, interviewing should not be a scary process, but more of a find-some-buddies-to-work-with process.

The post Interviewing for a Technical Position Doesn’t Have to Be Scary appeared first on CSS-Tricks.

Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from Youtube
Vimeo
Consent to display content from Vimeo
Google Maps
Consent to display content from Google