The beginner’s guide to usability testing

You are not your users. But if you can find your users and learn from them as you design, you’ll be able to create a better product.

Usability testing comes in many forms: casual cafeteria studies, formal lab testing, remote online task-based studies and more. However you choose to carry out your testing, you’ll need to go through these five phases:

• Prepare your product or design to test
• Find your participants
• Write a test plan
• Take on the role of moderator
• Present your findings

That’s it. A usability test can be as basic as approaching strangers at Starbucks and asking them to use an app. Or it can be as involved as an online study with participants responding on a mobile phone. But all usability tests need these five elements.

Usability testing can be as simple as listening to people as they use a prototype of your app for a few minutes in a cafeteria.

Usability testing is effective because you can watch potential users of your product to see what works well and what needs to be improved. It’s not about getting participants to tell you what needs adjusting. It’s about observing them in action, listening to their needs and concerns, and considering what might make the experience work better for them.  

Early on, usability tests in computer science were conducted primarily in academia or large companies such as Sun, Bell Labs, Sun, HP, AT&T, Apple and Microsoft. The practice of usability testing grew in the mid-1980s with the start of the modern usability profession, and books and articles popularised the method. With the explosion of digital products, it’s continued to gain popularity because it’s considered one of the best ways to get input from real users.

A common mistake in usability testing is conducting a study too late in the design process. If you wait until right before your product is released, you won’t have the time or money to fix any issues – and you’ll have wasted a lot of effort developing your product the wrong way. Instead, conduct several small-scale tests throughout the cycle, starting as early as paper sketches.

Create a design or product to test

How do you decide what to test? Start by testing what you’re working on.

• Do you have any questions about how your design will work in practice, such as a particular interaction or workflow? Those are perfect.
  
• Are you wondering what users notice on your home page? Or what they would do first? This is a great time to ask.
  
• Planning to redesign a website or app? Test the current version to understand what’s not working so you can improve upon any issues.

Once you know what you’d like to test, come up with a set of goals for your study. Be as specific as possible, because you’ll use the goals to come up with the particular study tasks. A goal can be broad, such “ Can people navigate through the website to find the products they need?” Or they can be specific, such as “Do people notice the link to learn more about a particular product on this page?”

Sometimes a paper sketch is enough to get you started with testing.

You also need to figure out how to represent your designs for the study. If you’re studying a current app or website, you can simply use that. For early design ideas, you can use a paper “prototype” made from pencil sketches or designed through software such as PowerPoint.

If you’re farther along in your ideas and want something more representative of the interactions, you can create an interactive prototype using a tool such as Balsamiq or Axure. Whatever you create, make sure it will allow participants to perform the tasks you want to test.

Find your participants

When thinking about participants, consider who will be using your product and how you can reach those people.  

If you have an app that targets hikers, for example, you could post your request on a Facebook page for hikers. If your website targets high school English teachers, you could send out a request for participants in educational newsletters or websites. If you have more money, hire a recruiting firm to find people for you (don’t forget to provide screener questions to find the right people). If you have no money,  reach out to friends and family members and ask if they know anyone who meets your criteria.

Screeners like this one help you connect with the right participants.

Be prepared. Participant recruiting is often one of the lengthier parts of any usability study, and should be one of the first things you put into action. This way as you’re working on other parts – like writing your tasks and questions – the recruitment process will be progressing concurrently.

You might also wonder how many participants you will need. Usability expert Jakob Nielsen says testing five people will catch 85% of the usability issues with a design – and that you can catch the remaining 15% of issues with 15 users. Ideally then, you should test with five users, make improvements, test with five more, make improvements, and test with five more. (As a general rule, recruit at least one more participant than you need, because typically one person will not show up.)

No matter who you’re testing, you’ll want to offer some sort of incentive, such as cash or a gift card, for participants’ time. The going rate is different in different parts of the world. Generally, you should charge more if the test in-person (because participants have to travel to get there), and less if it’s remote, through a service such as WebEx. Audiences that are hard to reach – such as doctors or other busy and highly trained professionals – will require more compensation.

Write a test plan

To keep yourself organised, you need a test plan, even if it’s a casual study. The plan will make it easy to communicate with stakeholders and design team members who may want input into the usability test and, of course, keep yourself on track during the actual study days. This is a place for you to list out all the details of the study. Here are potential study plan sections:

• Study goals: The goals should be agreed upon with any stakeholders, and they are important for creating tasks.
• Session information: This is a list of session times and participants. You can also include any information about how stakeholders and designers can log into sessions to observe. For example, you can share – and record – sessions using WebEx or gotomeeting.
• Background information and non-disclosure information: Write a script to explain the purpose of the study to participants; tell them you’re testing the software, not them; let them know if you’ll be recording the sessions; and make sure they understand not to share what they see during the study (having participants sign a non-disclosure agreement as well is a best practice). Ask them to please think aloud throughout the study so you can understand their thoughts.
• Tasks and questions: Start by asking participants a couple of background questions to warm them up. Then ask them to perform tasks that you want to test. For example, to learn how well a person was able to navigate to a type of product, you could have them start on the home page and say, “You are here to buy a fire alarm. Where would you go to do that?” Also consider any follow-up questions you might want to ask, such as “How easy or difficult was that task?” and provide a rating scale.
• Conclusion: At the end of the study, you can ask any observers if there are questions for the participant, and ask if the participant has anything to else they’d like to say.

It might help to start your test plan with a template.

Take on the role of moderator

It’s your job as moderator – the one leading usability sessions – to make sure the sessions go well and the team gets the information they need to improve their designs. You need to make participants feel comfortable while making sure they proceed through the tasks, and while minimising or managing any technical difficulties and observer issues. And stay neutral. You can do this!

The test plan is your guide. Conducting a pilot study – or test run – the day before the actual sessions start also helps your performance as a moderator because you get to practice working through all the aspects of the test.

Observe and listen

As you go through the study with participants, remember that it’s your job to be quiet and listen; let the participants do the talking. That’s how you and your team will learn. Be prepared to ask “why?” or say “Tell me more about that” to get participants to elaborate on their thoughts. Keep your questions and body language neutral, and avoid leading participants to respond a certain way.

During the sessions, someone will need to take notes. Ideally, you’ll have a separate note-taker so you can focus on leading sessions. If not, you’ll need to do this while moderating. Either way, set up a note-taking sheet in a spreadsheet tool (I use Excel) to simplify the process both now and when analysing the data. One organised way to do this is to have each column represent a participant, and each row a question or task. Learn more about writing effective research observations.

In addition to taking notes, plan to record the sessions using a tool such as WebEx or Camtasia as a backup, just in case you miss something. You’ll find a useful list of tools here.

Make sure you prepare for things to go wrong (and something always does). Consider the following:

• Some participants will be a few minutes late. If they are, but you still want to use them, what are the lowest priority tasks or questions that you will cut out?
• The prototype software could stop working or have a bug. Try to have a backup – such as paper screenshots – if you think this is a possibility.
• In a remote study, some participants will have difficulty using the video conferencing tool. Know in advance how the screen looks to them, what they should do, and common things that can go wrong so you can guide them through the experience.

Remote testing

If you’re conducting a remote unmoderated study, a remote tool – such as UserZoom or Loop11 – takes the place of the moderator. Because of the extra distance, you need to write your introduction to set the tone and provide background information about the study; effectively present the tasks; and keep users on track. It’s important to do as much as possible to test remote studies before launching them to prevent technical difficulties as well.

Present your findings

As you’re going through your sessions, it’s a good idea to jot down themes you notice, especially if they’re related to the study’s goals. Consider talking with observers after each session or at the end of each day to get a sense of their main learnings. Once the sessions are over, comb through your notes to look for more answers to the study’s stated goals, and count how many participants acted certain ways and made certain types of comments.  Determine the best way to communicate this information to help stakeholders.

Callouts are useful to draw attention to users’ quotes or points in the presentation of results.

Consider these methods of documenting your findings:

• If your audience is an agile team that needs to start acting on the information right away, an email with a bulleted list of findings may be all you need. If you can pair the email with a quick chat with team members, the team will process the information better.
• A PowerPoint presentation can be a great way to document your findings, including screenshots with callouts, and graphs to help make your points stand out. You can even include links to video clips that illustrate your points well.
• If you’re in a more academic environment, or your peers will read a report, write up a formal report document. Don’t forget to include images to illustrate your findings.

Where to next?

These resources can serve as excellent references on usability testing:

• Don’t Make Me Think and Rocket Surgery Made Easy by Steve Krug
• Observing the User Experience by Mike Kuniavsky
• Handbook of Usability Testing by Jeffrey Rubin and Dana Chisnell

Once you master the basics of usability testing, you can expand into other types of testing such as:

• Remote moderated testing (same as lab testing, only your participants are somewhere else, and you communicate through WebEx or a similar tool and a phone)
• Remote unmoderated testing (usability testing with hundreds of people through a tool such as UserZoom or Loop11)
• A/B testing (testing two designs against each other to see which performs better)
• competitive testing (pitting your design against your competitors’ designs)
• benchmark studies (testing your site or app’s progress over time)

Usability testing is a critical part of the user-centered design process because it allows you to see what’s working and what’s not with your designs. Challenge yourself to get more out of your sessions by using at least one new idea from this article during your next – or first – round of testing.

Still have questions about usability testing? Chat to Cindy in our upcoming Ask the UXperts session: Usability Testing: Digging into the Details. 

3pm Wednesday 30 November PDT or 10am Thursday 1 December AEST (or find out what time that is for you)

The post The beginner’s guide to usability testing appeared first on UX Mastery.

by Cindy McCracken via UX Mastery

We Quit Facebook and Google to Build a Children’s Book Startup

The story of my startup, Read Your Story, begins on a warm summer evening in July 2015, when my family was having dinner over at my sister’s house in Palo Alto, California.

While we were enjoying some wine, we watched our kids play in the backyard. As we were chatting, the conversation at some point turned to how much we loved storytime with our kids, since it’s an opportunity to bond and escape technology.

Like many other parents, we were concerned about limiting "screen time" for our own children.

The iPhone and iPad are magnificent devices, but they are also far too convenient as tools for zoning out unruly kids when we need a moment of peace.

My sister Jeanette — then a marketer at Google — asked an interesting question: is it possible to make books that are more engaging than an iPad for young kids?

We started to brainstorm and began to share some interesting observations about young children. We consistently noticed kids get excited when they see their own name in print, and also when they see pictures of themselves.

Why couldn’t we merge names and pictures into storybooks?

From this dinner followed several weeks of research, where my sister and I were surprised to discover that there were surprisingly few personalized children’s book companies that merged faces and names into books.

And the ones that existed were poor quality. We decided that we could do better.

As an experiment, we committed to a short-run book test test to validate market demand.

At the time, I was working at Facebook as a product manager and wasn’t ready to leave my job.

We kept this project on a slow and steady burn as a side project.

Validating the Concept Through a First Run

After brainstorming a few book concepts, we decided to go with an "ABC" book, since it was a straightforward and popular book format for parents.

Jeanette ran some hefty diligence through her network and was able to connect with Donna — an incredible children’s book illustrator who brought our book to life. Donna later became our third co-founder.

The goal for our first run wasn’t to make money, but to validate directional product/market fit.

We committed to making 50 books.

When we were ready to launch our test in October, we had a really solid product to test with — but a terrible user experience.

I constructed a crude SquareSpace website that featured an awful shopping experience.

If you wanted to buy a book, you had to:

1. Fill out a form with your child’s details, shipping details, and your email.
2. Give us your credit card information to make a purchase.
3. Our team would see the order and then email the customer soliciting a photo of their child.
4. Upon receiving the customer’s photo, our team would manually crop the face into each page of the book.
5. Finally, the book was sent to a printer and drop-shipped to the customer.

Each book took 3 hours to create in Photoshop.

There was a ton of manual drawing that was required for every page of the book — it turns out that masking artificial hair on top of a real face is quite challenging!

After creating a customer’s book, we would then export a high-quality PDF and upload it to Blurb.com, a really great but expensive photo book tool.

We sold each book for $35 on our website, and Blurb would then charge us $45 to print and deliver.

Most importantly, my sister and I wanted to get unbiased data that real people wanted our books. Consequently, we didn’t let any friends know about our project. We shared news of these books to lists and parent groups under aliases.

We also ran some light Facebook ads to drive brand awareness and a little direct response. We purposely held off on being too aggressive with marketing.

We wanted to see what customers would do with the books.

Fortunately, the reaction was really positive, even with the poor user experience. Our customers shared our site and told their friends, and much of our sales turned out to be organic via word of mouth.

No profit was made from this test run, but we were able to prove some demand for our idea.

How to get 6,000 customer signups before you launch

After our successful mini-run test, we decided to proceed with testing a more scalable version of our business. But first we wanted to build a customer list to further validate demand.

Even before fingers touch code to develop your cool new business, I’m a big believer that you have to determine market validation so that you can sell your product.

List building is one of the best levers to both validate product/market fit, as well as line up customers from day one.

The co-founders at Read Your Story had a strong gut-feel that our customized children’s books would be received well in the market. However, we were starting a brand from scratch. How the hell were we going to validate scalability for our business?

For us, we did that through Facebook ads.

Step 1: Get Likes to your Facebook Page

We kicked things off by setting up a simple Facebook page.

A nice logo, nice cover image, and a few cute posts. Then, we launched a Facebook ad campaign that was optimized for people to like our Page.

I’m a former Facebook Ads product manager, and do not generally recommend optimizing for Likes.

Basically what happens when you do this is that the audience that Facebook targets focuses more on people who are ‘Like-y’.

That is, you’ll get people who just tend to Like everything that they see. Thus, the audience that you attract via these kinds of campaigns may not be a true signal of actual people who are interested in your product, but it is at least some rough signal.

Didn’t matter for me though. My primary focus was a single number: 100.

I wanted to put together a rough audience that had a general interest in my company, and aggregate 100 of these people.

Once I hit that number, I would then be able to run a Lookalike audience off those fans (you need a minimum of 100 fans to run Lookalike ads).

Step 2: Run Better & Better Lookalikes

Lookalikes are your best friend.

Continue reading %We Quit Facebook and Google to Build a Children’s Book Startup%

by Eric Bahn via SitePoint

Getting up and Running with the Vue.js 2.0 Framework

Back in September, the popular JavaScript framework Vue.js released v2 and ever since I've been really eager to give it a spin and see what it's like to work with. As someone who's pretty familiar with Angular and React, I was looking forward to seeing the similarities and differences between them and Vue.

Vue 2 sports excellent performance stats, a relatively small payload (the bundled runtime version of Vue weighs in at 16kb once minified and gzipped), along with updates to companion libraries like vue-router and vuex, the state management library for Vue. There's far too much to cover in just one article, but keep an eye out for a later article where we'll look more closely at some of the libraries that couple nicely with the core framework.

Inspiration from Other Libraries

As we go through this tutorial you'll see many features that Vue has that are clearly inspired by other frameworks. This is a good thing; it's great to see new frameworks take some ideas from other libraries and improve on them. In particular, you'll see Vue's templating is very close to Angular, but its components and component lifecycle methods are closer to React (and Angular 2, as well).

One such example of this is that, much like React and nearly every framework in JavaScript land today, Vue uses the idea of a virtual DOM to keep rendering efficient. Vue uses a fork of snabbdom, one of the more popular virtual DOM libraries. The Vue site includes documentation on its Virtual DOM rendering, but as a user all you need to know is that Vue is very good at keeping your rendering fast (in fact, it performs better than React in many cases), meaning you can rest assured you're building on a solid platform.

Components, Components, Components

Much like other frameworks these days, Vue's core building block is the component. Your application should be a series of components that build on top of each other to produce the final application. Vue.js goes one step further by suggesting (although not enforcing) that you define your components in a single .vue file, which can then be parsed by build tools (we'll come onto those shortly). Given that the aim of this article is to fully explore Vue and what it feels like to work with, I'm going to use this convention for my application.

A Vue file looks like so:

<template>
  <p>This is my HTML for my component</p>
</template>

<script>
export default {
  // all code for my component goes here
}
</script>

<style scoped>
  /* CSS here
   * by including `scoped`, we ensure that all CSS
   * is scoped to this component!
   */
</style>

Alternatively, you can give each element a src attribute and point to a separate HTML, JS or CSS file respectively if you don't like having all parts of the component in one file.

Setting up a Project

Whilst the excellent [Vue CLI][http://ift.tt/1JBk14p] exists to make setting up a full project easy, when starting out with a new library I like to do it all from scratch so I get more of an understanding of the tools.

These days Webpack is my preferred build tool of choice, and we can couple that with the vue-loader plugin to support the Vue.js component format that I mentioned previously. The final thing we'll need is Babel and the ES2015 preset, so we can write all our code in lovely ES2015 syntax.

Setting up the Webpack configuration boils down to the following:

• Make Webpack build from src/main.js, and output into build/main.js
• Tell Webpack to use the vue-loader for any .vue files
• Tell Webpack to use Babel for any .js files
• Tell the vue-loader that it should use Babel to transpile all JavaScript. This means that when we include JavaScript in our *.vue files, it will be transpiled through Babel.

module.exports = {
  entry: './src/main',
  output: {
    path: './build',
    filename: 'main.js',
  },
  module: {
    loaders: [
      {
        test: /\.vue$/,
        loader: 'vue',
      },
      {
        test: /\.js$/,
        loader: 'babel',
        exclude: /node_modules/,
      },
    ],
  },
  vue: {
    loaders: {
      js: 'babel',
    },
  },
}

Finally, we'll create an HTML file and we're ready to go!

<!DOCTYPE html>
<html>
  <head>
    <title>My Vue App</title>
  </head>
  <body>
    <div id="app">
    </div>
    <script src="/build/main.js"></script>
  </body>
</html>

We create an empty div with the ID of app as this is the element that we're going to place our Vue application in. I always prefer to use a div, rather than just the body element, as that lets me have control over the rest of the page.

Writing Our First Vue.js App

We're going to stay true to every programming tutorial ever and write a Vue application that puts "Hello World" onto the screen before we dive into something a bit more complicated.

Each Vue app is created by importing the library and then instantiating a new Vue instance:

import Vue from 'vue'

const vm = new Vue({
  el: '#app',
})

We give Vue an element to render onto the page, and with that, we've created a Vue application! We pass a selector for the element that we want Vue to replace with our application. This means when Vue runs it will take the div#app that we created and replace it with our application.

The reason we use the variable name vm is because it stands for "View Model". Although not strictly associated with the "Model View View-Model" (MVVM) pattern, Vue was inspired in part by it, and the convention of using the variable name vm for Vue applications has stuck. Of course, you can call the variable whatever you'd like!

So far, our application isn't doing anything, though, so let's create our first component, App.vue, that will actually render something onto the page.

Vue doesn't dictate how your application is structured, so this one is up to you; I ended up creating one folder per component, in this case App (I like the capital letter, signifying a component), with four files in it:

• index.vue
• template.html
• script.js
• style.css

App/index.vue simply imports the other three files:

<template src="./template.html"></template>
<script src="./script.js"></script>
<style scoped src="./style.css"></style>

I like calling it index.vue, but you might want to call it app.vue too so it's easier to search for. I prefer importing App/index.vue in my code versus App/app.vue, but again you might disagree, so feel free to pick whatever you and your team like best.

For now, our template is just <p>Hello World</p>, and I'll leave the CSS file blank. The main work goes into script.js, which looks like so:

export default {
  name: 'App',
  data() {
    return {}
  },
}

Doing this creates a component which we'll give the name App, primarily for debugging purposes, which I'll come onto later, and then define the data that this component has and is responsible for. For now, we don't have any data, so we can just tell Vue that by returning an empty object. Later on, we'll see an example of a component using data.

Now we can head back into src/main.js and tell the Vue instance to render our App component:

Continue reading %Getting up and Running with the Vue.js 2.0 Framework%

by Jack Franklin via SitePoint

Animated Intro With jQuery

A simple snippet about creating animated intro with progress bar by using jQuery and CSS.

by via jQuery-Plugins.net RSS Feed

Seven Ways You Can Place Elements Using CSS Grid Layout

In this article, we are going to learn seven ways in which you can place elements in a web page using the Grid Layout module.

Previously, SitePoint published Introducing the CSS Grid Layout and An Introduction to the CSS Grid Layout Module. Recently, I also wrote Where Things Are at in the CSS Grid Layout Working Draft.

Here, the focus will be entirely on specific ways in which you can lay out elements on the web using CSS Grid. Now, let's go over each one of them.

Addressing the Poor Support for Grid Layout

As I mentioned in previous articles, Grid Layout has very poor browser support. None of the major browsers support it by default and IE supports the old implementation. To properly work with all the examples in this article, I suggest that you enable the "Experimental Web Platform features" flag in Chrome and the "layout.css.grid.enabled" flag in Firefox. For readers who find it problematic to enable these flags, I have added a screenshot to show the final result of each technique.

#1 Specifying Everything in Individual Properties

This is the version we have been using to place the elements in our previous articles. This method is verbose but easy to understand. Basically, the left/right and top/bottom bounds of an element are specified using grid-column-start/grid-column-end and grid-row-start/grid-row-end properties. If an element is only going to span one row or column, you can omit the -end properties, this way you will have to write a little less CSS.

In the demo below, element A has been placed in the second row and second column using the following CSS:

[code language="css"]
.a {
grid-column-start: 2;
grid-column-end: 3;
grid-row-start: 2;
grid-row-end: 3;
}
[/code]

The same effect could be achieved by using:

[code language="css"]
.a {
grid-column-start: 2;
grid-row-start: 2;
}
[/code]

See the Pen Specifying Everything in individual Properties by SitePoint (@SitePoint) on CodePen.

#2 Using grid-row and grid-column

Even though the CSS in our first example was readable and easy to understand, we had to use four different properties to place a single element. Instead of using four properties, we can just use two — grid-column and grid-row. Both these properties will take two values separated by a slash where the first value will determine the start line and the second value will determine the end line of our element.

Here is the syntax you need to use with these properties:

[code language="css"]
.selector {
grid-row: row-start / row-end;
grid-column: col-start / col-end;
}
[/code]

To place item C in the bottom right corner of our grid, we can use the following CSS:

[code language="css"]
.c {
grid-row: 2 / 4;
grid-column: 2 / 4;
}
[/code]

See the Pen Using grid-row and grid-column by SitePoint (@SitePoint) on CodePen.

Continue reading %Seven Ways You Can Place Elements Using CSS Grid Layout%

by Nitish Kumar via SitePoint

You Don’t Know Jacks: Learn to Make Your Code More Secure

This article was sponsored by Codiscope. Thank you for supporting the sponsors who make SitePoint possible.

I used to play a game called You Don’t Know Jack. It’s a trivia game, set as a game show, in which it’s fun to lose. Upon giving an incorrect answer, the player is treated to a witty and irreverent reprimand from the game’s host.

It’s also an abject lesson in how little details mean the difference between getting something right and getting something horribly, embarrassingly wrong.

Recently, I was asked to write about Jacks. I’d never heard of it before, but it was immediately interesting to me. You see, there aren’t many services that claim to help you as you learn about how to code securely. Jacks wants to be that service. Almost like a coach. That never sleeps. And costs nothing.

Unlike the trivia game, it’s more forgiving. That’s great when you really don’t know what you’re doing — as I found out when I decided to learn a new web framework.

Most of the code for this post can be found on Github . I’ve tested it in Node 7.0.0, on macOS Sierra 10.12.1.

Getting Hapi

I’ve written many little NodeJS applications, and I’ve often found Express to be just enough for my web application needs. But I’ve also wondered how best to structure a much larger application. There are opinionated options, like Adonis, but I’m already quite familiar with it. What new thing could I learn, while also kicking Jacks’ tires?

And then I saw mention of Hapi on Jacks’ home page .

I opened my terminal, made a new project folder, and installed Hapi:

yarn add hapi

You can also install Hapi using NPM. I’m just a sucker for trends, and Yarn is pretty darn fast!

According to the docs, making a Hapi application is as easy as:

"use strict"

const hapi = require("hapi")

const server = new hapi.Server()

server.connection({
    "port": 3000,
})

server.route({
    "method": "get", "path": "/",
    handler: function (request, reply) {
        reply("hello world")
    },
})

server.start(err => {
    if (err) {
        throw err
    }

    console.log("server at " + server.info.uri)
})

This is from index.js.

If you’ve used Express, this should look somewhat familiar to you. I’ve created a new HTTP server, with a single route. When a browser requests /, this route will reply with hello world:

Plugging In

The next step was to connect my Github account to Jacks. Creating a Jacks account was rather effortless, and free. First I set up a new project:

…and then I connected my Github account (and the project repository) to Jacks:

This all took about 2 minutes, from start to finish.

Making Mistakes

Now it was time to see just how helpful Jacks could be. I got together a list of common web app security mistakes, and decided to try a few, to see what Jacks would say (and how it could teach me to be better at my job).

Content Security Policy

At this point, I wasn’t expecting Jacks to have any recommendations for me yet. But, when I went back to the interface, I saw the first bit of advice it had to offer me:

It took a bit of searching for a good explanation, but I finally found one at Content Security Policy CSP Reference & Examples. CSP is essentially a way of restricting where HTTP resources may be loaded from. This is great because malicious users who might have been able to inject custom scripts and/or images wouldn’t be able to exploit those vulnerabilities as easily.

Jacks also provided example code for how to add Blankie to my server script:

"use strict"

const hapi = require("hapi")
const blankie = require("blankie")
const scooter = require("scooter")

const server = new hapi.Server()

// ...create server + connection + routes

server.register([scooter, {
    "register": blankie,
    "options": {
        // ..CSP directives here
        "defaultSrc": "self",
    }
}], err => {
    // ...start server
})

This is from index.js.

I needed to install Blankie and Scooter, with yarn add blankie and yarn add scooter, for this code to work. These add CSP headers to each request:

Sure enough, as soon as I committed that code to the project, Jacks noticed it and marked the recommendation as resolved.

Disabling Directory Listings

A common security pitfall is enabling (or rather not appropriately disabling) directory listings in web apps. There’s a popular Hapi plugin, called Inert, which enables static file serving and directory listings. It’s not uncommon to enable these features, so that’s what I tried to do:

Continue reading %You Don’t Know Jacks: Learn to Make Your Code More Secure%

by Christopher Pitt via SitePoint

Animations: Using Easings to Craft Smarter Interactions

By changing the length and speed of your animations, you can create some very unique transitions, and even enhance the user experience of micro-interactions.

How something animates (i.e. its motion) is called an easing, and when smartly fine-tuned, these easings can help micro-interactions chaperone the user safely throughout your UI, contribute to a visual aesthetic, or even alter the user’s mood.

How? Lets take a look.

Easings Can Make Interfaces Animate Naturally

In real life, objects rarely move at constant speed. When we open doors, for instance, we open them quickly at first and then slow down towards the end, because that’s how our muscles work. If you bounce a ball on the floor, it rises quicker at first, slows down, and then drops to the floor due to gravity.

[caption id="attachment_144396" align="aligncenter" width="800"] Dribbble Bouncing Balls by Tidjane Tall[/caption]

Part of how we navigate and interact with our world is dictated by our understanding of how objects move. Would you involuntarily try to catch an object if it were suspended in mid-air? Probably not. Would you attempt to board a moving train? Definitely not. Our brains understand natural motion, and that’s why crafting easings that animate in a natural way will help your users understand them more easily.

Let's take our first look at an easing.

Types of Easings

Seeing easings in action is the best way to understand them. Many programming languages (like CSS) and frameworks (like jQuery) have a set of ready-made easing functions built-in — if you take a look at Easings.net you’ll be able to witness a selection of them.

[caption id="attachment_144390" align="aligncenter" width="860"] Easings by Easings.net[/caption]

Consider a double-sided card interface (perhaps credit card information on the front, security code on the back) — you would flip the credit card to read the security code. You wouldn’t do this at constant speed (linear easing), but you also wouldn’t use any fancy motions to do it (elastic or bounce easings).

[caption id="attachment_144394" align="aligncenter" width="800"] Checkout Animated Flow by Alyona Syvokobylska[/caption]

A simple ease motion would suffice, meaning that one state simply eases into another. If an element on the screen dropped from the top of the screen to the bottom, that might warrant a bounce easing because some objects bounce when dropped.

[caption id="attachment_144393" align="alignright" width="400"] Alert Popup by Jayson Lane[/caption]

How Does Ease-In Differ From Ease-Out?

Ease-in is slow at the beginning, fast at the end — ease-out is the opposite. As a general rule you should use ease-in when something is moving out, and ease-out when something is moving in. Ease-in-out is slower at the beginning and end.

In fact, Google has some very specific ideas about how fast elements should transition in-and-out, and the acceleration/deceleration of the speed.

Easings Can Guide the User Safely

A bounce easing is more eye-catching, making it suitable for error messages and popup dialogs, whereas a simple ease transition doesn’t steal too much time and focus from the user, making them more suitable for micro-interactions.

The type of easing you choose should depend on how much attention the animated element warrants, and the sort of action is that is required from the user – different easings communicate different things.

[caption id="attachment_144395" align="aligncenter" width="800"] Button With Success/Error States by Andrei Mironov[/caption]

Guiding the user safely is no easy task; it’s a collaborative effort between animation, color, and even the use of words; each can contribute to effectively communicating to the user what they should do next, or where they should go.

How Long Should an Animation Last?

For ease animations, something between 200ms-500ms is optimal; this gives the human brain enough time to “read” the animation and decide what the user should do next, without delaying the user too much. If the animation is too long the user is forced to wait; too short and it’ll feel uncomfortably sharp, both of which are very annoying to the user.

Elastic or bounce easings should have a longer duration (around 800ms-1200ms) to allow the animation to flow. Without this added time the animation will feel aggressively jolty.

Easings Can Influence Mood

In a similar way to colours and typography, animation can influence the mood of the user. You can fine-tine the duration and easing of an animation to influence how a user feels.

Slower animations can imply elegance or seriousness (depending on the nature of the app/website), whereas faster animations can convey something more upbeat. Your mood can affect your decision-making (i.e. a slower, more serious tone might convince you to donate to a charity, and a faster, more upbeat tone might make you feel more impulsive and more likely to spend money).

Since experts generally tend to agree on the duration of easings for micro-interactions, there isn’t much room to apply branding in this respect. Animation in branding is still a relatively untouched topic, however, as a rule, I would save complex animations for larger components (modals, et cetera) and illustrations (you can animate SVG in web design for example!).

Continue reading %Animations: Using Easings to Craft Smarter Interactions%

by Daniel Schwarz via SitePoint