Stop Facebook from showing you the same ads [video]

Ever notice Facebook is really good at serving you ads based on everything you click on, like, and interact with on the site? Here's how to change that.

[ This is a content summary only. Visit our website http://ift.tt/1b4YgHQ for full links, other content, and more! ]

by Web Desk via Digital Information World

The Dark Side of the Internet [Infographic]

The term Dark Web is evocative. It conjures up images of hitmen, illegal drugs, and pedophilia. One imagines a place where the dark side of human nature flourishes away from the eyes – and laws – of society at large. Today’s infographic, from Cartwright King Solicitors, cuts through the mystique...

[ This is a content summary only. Visit our website http://ift.tt/1b4YgHQ for full links, other content, and more! ]

by Web Desk via Digital Information World

Ask the UXperts: What’s Wrong With Your Portfolio — with Joe Natoli

If there’s anyone that knows how to build a good portfolio it’s Joe Natoli and that’s not just because he’s been in this game for a while.

Joe’s recent series of workshops called Give Good Portfolio were focused on teaching aspiring UXers to build the kind of competitive, effective, impactful UX portfolio that recruiters, employers and prospective clients want to see.

We love Joe because he is full of practical takeaways and actionable advice. If you’re struggling to convert your job interviews or you have questions about the best way to present your work, this is the session for you.

The Details

• Where: Our dedicated ‘Ask the UXperts’ Slack channel (You’ll need to request an invitation if you haven’t yet joined our Slack channel)
• When: 3pm Wednesday 27 Sept PDT or 8am Thursday 28 Sept AEST (or find out what time that is for you)

Meet Joe Natoli

Joe Natoli has been preaching and practicing the gospel of User and Customer Experience to Fortune 100, 500 and Government organizations for nearly three decades.

Joe devotes half of his practice to writing, coaching, and speaking. From guiding students at the beginning of their careers to integrating UX into the work of seasoned veteran developers and designers, he is immensely passionate about the inherent power of UX and design.

The remaining half of Joe’s practice is dedicated to training Enterprise Design and Development teams, helping them integrate best practices in UX into their product development efforts.

Joe runs a series of workshops called Give Good Portfolio. Keep your eyes peeled for his upcoming course on the same subject.

How to Ask Your Questions

If you can’t make the live session but have questions, we’d love to collect them ahead of time and we’ll ask Joe on your behalf. You can ask them in the comments below. We’ll publish the responses (along with the full transcript) in the days following the session.

Here are a few questions to get you started:

1. What do employers and clients really want from a portfolio?
2. How much damage can a bad portfolio do?
3. Should I include all my projects in my portfolio, even if they’re not well documented?

How does Ask the UXperts work?

These sessions run for approximately an hour and best of all, they don’t cost a cent. We use a dedicated public Slack channel. That means that there is no audio or video, but a full transcript will be posted up on here in the days following the session.

The post Ask the UXperts: What’s Wrong With Your Portfolio — with Joe Natoli appeared first on UX Mastery.

by Sarah Hawk via UX Mastery

Web Design Weekly #290

Headlines

AMPersand

Ethan Marcotte shares his opinions about Google’s “Accelerated Mobile Pages” (AMP) project. Good read. (ethanmarcotte.com)

The average web page is 3MB. How much should we care? (speedcurve.com)

Why the Internet is Going Crazy Over This Mattress

The Casper mattress is obsessively engineered and sleeps cool. Plus it ships for FREE, straight to your door. Web Design Weekly readers get $50 off with code: wdweekly. (casper.com)

Articles

From Modular Scales to Variable Fonts

Scott Kellum, developer and designer, talks about using modular scales when setting type and why he is excited about the arrival of variable fonts for the web. (medium.com)

A Guide To Virtual Reality For Web Developers

In this article, Ada Rose Edwards looks at the state of browsers in VR and the state of VR on the web via the WebVR APIs. (smashingmagazine.com)

Yes, That Web Project Should Be a PWA

Progressive Web Apps may seem overly technical or beyond the needs of your project, but they’re really not. (alistapart.com)

Writing Scalable React Apps with the Component Folder Pattern

Discover how to organise your React components using the component folder pattern. It will help un-clutter your projects, and focus on writing good code. (medium.com)

Decaffeinating a Large CoffeeScript Codebase

Over the course of two months, the engineering team at DataFox converted their web application codebase from CoffeeScript to ECMAScript 2015. This post outlines their conversion process and provides some practical tips. (eng.datafox.com)

Compression Decompressed

If you are keen to nerd out about compression this is for you. (unwttng.com)

Introducing visualViewport (developers.google.com)

Tools / Resources

Switching Your Site to HTTPS on a Shoestring Budget

If you haven’t set up a site to be served over HTTPS it can be confusing and sometimes expensive. Thankfully Christopher Schmitt has put together this handy guide to point you in the right direction. (css-tricks.com)

Conducting the Technical Interview

If you happen to be in the position of interviewing new candidates for an open role and lack experience this article by Brandon Gregory is a great starting point. (alistapart.com)

RESTool

An open source UI tool for managing RESTful APIs. (medium.com)

Key Values

A new job site that aims to connect you with teams that share the same values. (keyvalues.io)

Enoki

An ultralight set of tools for publishing on the open and distributed web. (enoki.site)

A CSS in JS playground demoing some common libraries (dschau.github.io)

Using Code Snippets in Chrome Developer Tools (alexkras.com)

New in Chrome 61 (developers.google.com)

Sketch Libraries (sketchapp.com)

TypeScript 2.5 (microsoft.com)

Inspiration

Design Details – Say More Things with Josh Brewer (spec.fm)

Atlassian’s new identity (atlassian.com)

Jobs

Senior Product Designer at TripAdvisor

We are looking for a talented Senior UX/UI designer to design engaging experiences on TripAdvisor’s web and mobile platforms for travelers worldwide. (tripadvisor.com)

Product Designer at Atlassian

Join our brand new, fast-growing office in Mountain View as a Senior Designer for one of our flagship products, Confluence. (atlassian.com)

Need to find passionate developers or designers? Why not advertise in the next newsletter

Last but not least…

Every Programmer Should Know (github.com)

The post Web Design Weekly #290 appeared first on Web Design Weekly.

by Jake Bresnehan via Web Design Weekly

How to Organize a Large React Application and Make It Scale

This article is by guest author Jack Franklin. SitePoint guest posts aim to bring you engaging content from prominent writers and speakers of the Web community

In this article, I'll discuss the approach I take when building and structuring large React applications. One of the best features of React is how it gets out of your way and is anything but descriptive when it comes to file structure. Therefore you'll find a lot of questions on StackOverflow and similar asking how to structure applications. This is a very opinionated topic, and there's no one right way. In this article, I'll talk you through the decisions I make when building React applications: picking tools, structuring files, and breaking components up into smaller pieces.

Build Tools and Linting

It will be no surprise to some of you that I'm a huge fan of Webpack for building my projects. Whilst it is a complicated tool, the great work put by the team into version 2 and the new documentation site make it much easier. Once you get into Webpack and have the concepts in your head you really have incredible power to harness. I use Babel to compile my code, including React-specific transforms like JSX, and the webpack-dev-server to serve my site locally. I've not personally found that hot reloading gives me that much benefit, so I'm more than happy with webpack-dev-server and its automatic refreshing of the page.

I also use the ES2015 module syntax (which is transpiled through Babel) to import and export dependencies. This syntax has been around for a while now and although Webpack can support CommonJS (aka, Node style imports), it makes sense to me to start using the latest and greatest. Additionally, Webpack can remove dead code from bundles using ES2015 modules which, whilst not perfect, is a very handy feature to have, and one that will become more beneficial as the community moves towards publishing code to npm in ES2015.

Configure Webpack's modules resolution to avoid nested imports

One thing that can be frustrating when working on large projects with a nested file structure is figuring out the relative paths between files. You'll find that you end up with a lot of code that looks like this:

import foo from './foo'
import bar from '../../../bar'
import baz from '../../lib/baz'

When you're building your app with Webpack you can tell Webpack to always look in a specific directory for a file if it can't find it, which lets you define a base folder that all your imports can become relative to. I always put my code in a src directory. I can tell Webpack to always look in that directory. This is also where you need to tell Webpack about any other file extensions that you might be using, such as .jsx:

// inside Webpack config object
{
  resolve: {
    modules: ['node_modules', 'src'],
    extensions: ['.js', '.jsx'],
  }
}

The default value for resolve.modules is ['node_modules'], so you have to add it too else Webpack won't be able to import files that you've installed with npm or yarn.

Once you've done that you can always import files relative to the src directory:

import foo from './foo'
import bar from 'app/bar' // => src/app/bar
import baz from 'an/example/import' // => src/an/example/import

Whilst this does tie your application code to Webpack, I think it's a worthwhile trade-off because it makes your code much easier to follow and imports much easier to add, so this is a step I'll take with all new projects.

Folder Structure

There is no one correct folder structure for all React applications - as with the rest of this article, you should alter it for your preferences - but the following is what's worked well for me.

Code lives in src

To keep things organized I'll place all application code in a folder called src. This contains only code that ends up in your final bundle, and nothing more. This is useful because you can tell Babel (or any other tool that acts on your app code) to just look in one directory and make sure that it doesn't process any code it doesn't need to. Other code, such as Webpack config files, lives in a suitably named folder. For example, my top level folder structure often contains:

- src => app code here
- webpack => webpack configs
- scripts => any build scripts
- tests => any test specific code (API mocks, etc)

Typically the only files that will be at the top level are index.html, package.json, and any dotfiles, such as .babelrc. Some prefer to include Babel configuration in package.json, but I find those files can get large on bigger projects with many dependencies, so I like to use .eslintrc, .babelrc, and so on.

By keeping your app code in src, you can also use the resolve.modules trick I mentioned earlier which simplifies all imports.

React Components

Once you've got a src folder, the tricky bit is deciding how to structure your components. In the past, I'd put all components in one large folder, such as src/components, but I've found that on larger projects this gets overwhelming very quickly.

A common trend is to have folders for "smart" and "dumb" components (also known as container and presentational components), but personally I've never found explicit folders work for me. Whilst I do have components that loosely categorize into "smart" and "dumb" (I'll talk more on that below), I don't have specific folders for each of them.

We've grouped components based on the areas of the application that they are used, along with a core folder for common components that are used throughout (buttons, headers, footers - components that are generic and very reusable). The rest of the folders map to a specific area of the application. For example, we have a folder called cart that contains all components relating to the shopping cart view, and a folder called listings that contains code for listing things users can buy on a page.

Categorizing into folders also means you can avoid prefixing components with the area of the app that they are used for. As an example, if we had a component that renders the user's cart total cost, rather than call it CartTotal I might prefer to use Total because I'm importing it from the cart folder:

import Total from 'src/cart/total'
// vs
import CartTotal from 'src/cart/cart-total'

Continue reading %How to Organize a Large React Application and Make It Scale%

by Jack Franklin via SitePoint

How Facebook’s Algorithm Makes Zuckerberg the Most Powerful Human in History [video]

Facebook can flip your entire social identity on and off at the switch; that is way too much power for any institution to have over us, says Oliver Luckett, and we handed it to them.

[ This is a content summary only. Visit our website http://ift.tt/1b4YgHQ for full links, other content, and more! ]

by Web Desk via Digital Information World

React Quickly: How to Work with Forms in React

How to Work with Forms in React is an excerpt from React Quickly, a hands-on book by Azat Mardan for anyone who wants to learn React.js fast.

This article covers how to capture text input and input via other form elements like input, textarea, and option. Working with them is paramount to web development, because they allow our applications to receive data (e.g. text) and actions (e.g. clicks) from users.

The source code for the examples in this article is in the ch07 folder of the GitHub repository azat-co/react-quickly. Some demos can be found at http://ift.tt/2kq7Fch.

If you enjoy this post, you might also like to watch our course Build React Forms with Redux.

Recommended Way of Working with Forms in React

In regular HTML, when we work with an input element, the page's DOM maintains that element's value in its DOM node. It's possible to access the value via methods like document.getElementById('email').value, or by using jQuery methods. The DOM is our storage.

In React, when working with forms or any other user input fields, such as standalone text fields or buttons, developers have an interesting problem to solve. From React's documentation:

React components must represent the state of the view at any point in time and not only at initialization time.

React is all about keeping things simple by using declarative styles to describe UIs. React describes the UI, its end stage, and how it should look.

Can you spot a conflict? In the traditional HTML form elements, the state of the elements will change with the user input. React uses a declarative approach to describe the UI. The input needs to be dynamic to reflect the state properly.

If developers opt not to maintain the component state (in JavaScript), or not to sync it with the view, then it adds problems: there might be a situation when internal state and view are different. React won't know about changed state. This can lead to all sorts of trouble, and mitigates the simple philosophy of React. The best practice is to keep React's render() as close to the real DOM as possible, and that includes the data in the form elements.

Consider this example of a text input field. React must include the new value in its render() for that component. Consequently, we need to set the value for our element to new value using value. If we implement an <input> field as we always did it in HTML, React will keep the render() in sync with the real DOM. React won't allow users to change the value. Try it yourself. It drives me nuts, but it's the appropriate behavior for React!

render() {
  return <input type="text" name="title" value="Mr." />
}

The code above represents the view at any state, and the value will always be “Mr.”. With input fields, they must change in response to the user keystrokes. Given these points, let's make the value dynamic.

This is a better implementation, because it'll be updated from the state:

render() {
  return <input type="text" name="title" value={this.state.title} />
}

What is the value of state? React can’t know about users typing in the form elements. Developers need to implement an event handler to capture changes with onChange.

handleChange(event) {
  this.setState({title: event.target.value})
}
render() {
  return <input type="text" name="title" value={this.state.title} onChange={this.handleChange.bind(this)}/>
}

Given these points, the best practice is for developers to implement the following things to sync the internal state with the view (Figure 1):

1. define elements in render() using values from state
2. capture changes of a form element using onChange() as they happen
3. update the internal state in event handler
4. save new values in state and then update the view with a new render()

Figure 1: Capturing changes in input and applying to state

It might seem like a lot of work at first glance, but I hope that by using React more, you'll appreciate this approach. It's called a one-way binding, because state only changes views. There's no trip back, only a one-way trip from state to view. With one-way binding, a library won't update state (or model) automatically. One of the main benefits of one-way binding is that it removes complexity when working with large apps where many views can implicitly update many states (data models) and vice versa—Figure 2.

Simple doesn’t always mean less code. Sometimes, like in this case, developers must write extra code to manually set the data from event handlers to the state (which is rendered to view), but this approach tends to be superior when it comes to complex user interfaces and single-page applications with a myriad of views and states. To put it concisely: simple isn’t always easy.

Figure 2: One-way vs two-way binding

Conversely, a two-way binding allows views to change states automatically without developers explicitly implementing it. The two-way binding is how Angular 1 works. Interestingly, Angular 2 borrowed the concept of one-way binding from React and made it the default (you can still have two-way binding explicitly).

[affiliate-section title="Recommended Courses"][affiliate-card title="Job-Ready Angular and TypeScript Training" affiliatename="Todd Motto" text="The ultimate resource to learn Angular and its ecosystem. Use coupon code 'SITEPOINT' at checkout to get 25% off." url="http://ift.tt/2dOQnnQ" imageurl="http://ift.tt/2vNllRn"][/affiliate-section]

For this reason, we’ll cover the recommended approach of working with forms first. It's called controlled components and it ensures that the internal component state is always in sync with the view. The alternative approach is uncontrolled component.

So far, we’ve learned the best practice for working with input fields in React, which is to capture the change and apply it to state as depicted in Figure 1 (input to changed view). Next, let's look at how we define a form and its elements.

Continue reading %React Quickly: How to Work with Forms in React%

by Azat Mardan via SitePoint