emGee Software Solutions Custom Database Applications

Share this

Web Design

Error message

  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2063 of /homepages/18/d193362201/htdocs/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2073 of /homepages/18/d193362201/htdocs/includes/common.inc).

How To Build A Skin For Your Web App With React And WordPress

Smashing Magazine - Wed, 03/07/2018 - 04:00

So you’ve trained yourself as a web engineer, and now want to build a blazing fast online shop for your customers. The product list should appear in an instant, and searching should waste no more than a split second either. Is that the stuff of daydreams?

Not anymore. Well, at least it’s nothing that can’t be achieved with the combination of WordPress’ REST API and React, a modern JavaScript library.

Wait, What? WordPress REST API?

Yes, the WordPress REST API will help you build the back-end foundation for your web application. This is a good choice for your web application’s back-end technology if you are building a content-driven solution. WordPress will interoperate smoothly with other technologies as well; you could use Node.js as the focus of your application to connect to other RESTful services.

The WordPress REST API is a game-changer for WordPress, which can now safely be called a web application framework — not just a CMS. Now that the front- and back-end are completely decoupled, WordPress can be used as a mobile app back-end or as a back-end for any system focusing on content.

But why WordPress? The reason: You will be amazed at the functionalities that emerge out of the box with WordPress. You will get extensive user management, media management, and an incredibly developer-friendly set of APIs to extend your work.

In this article, I will walk you through building an SPA (Single Page Application) WordPress theme using the JavaScript library called React, connecting to the WP REST API.

“You must unlearn what you have learned!” Meet the brand new episode of SmashingConf San Francisco with smart front-end tricks and UX techniques. Featuring Yiying Lu, Aarron Draplin, Smashing Yoda, and many others. Tickets now on sale. April 17-18.

Check the speakers → Let’s Jump Into Building The Theme

This article assumes you are already familiar with the various existing WordPress APIs, particularly the ones that drive the development of themes for your site’s aesthetics, and functionalities for your site’s plugins. I also assume you have set up your development platform for WordPress, such as the LAMP stack in a Linux or MacOS environment.

For simplicity, though, I will refer only to absolute paths as visible with the XAMPP platform that is used with Windows.

Now, let’s create an instance of WordPress in our localhost, naming it ‘Celestial.’ That is the name of the WordPress theme we are going to use to help us set the direction for building future themes ready for use with web applications powered by the WordPress REST API. You may already be familiar with WordPress’ much-loved template hierarchy, but with the REST API, you have an opportunity to discover something different!

We then need to create a folder for the theme within the wp-content\themes folder. Navigate to C:\xampp\htdocs\celestial\wp-content\themes\ (or equivalent) and create a folder celestial. Add these files inside the celestial theme folder:

  1. index.php
    The catch-all file for the theme.
  2. style.css
    This contains information about the theme (and not actual CSS).
  3. functions.php
    To write the functionality and the importing of CSS and JS files.

Add an image file named screenshot.jpg if you want a picture for your theme showing inside the dashboard.

Note: The code for each file is a few lines long and can be found on GitHub.

Next, log in to your WordPress Dashboard, head over to AppearanceThemes and select ‘Celestial’ as the theme. Now that the foundation is in place, let’s get onto creating the theme.

You can select the 'Celestial' theme you created from the Themes panel in the dashboard. Getting Started With React And Webpack For The Theme

React is a very popular UI library supported and maintained by Facebook. According to Stack Overflow’s Developer Survey 2017 results, “React is the most loved among developers.”

React: A JavaScript library for building user interfaces.

For starting the project, you need to initialize the project as an NPM (Node Package Manager) project. This is done with the command npm init in the terminal (after having installed Node.js and NPM on your computer). Initializing the project will prompt you for certain configuration information. After successful initialization, NPM will create a package.json file in the theme’s root directory. This file will include the project details and all dependencies of the project.

React is now under MIT license, so we will be using version 16 of React as the JavaScript library for this project. React has some cool features under the hood, such as the Virtual DOM (a representation of the document within memory) and has a host of tools surrounding it such as the React Router. React is also used in the WordPress’ Project Calypso — the dashboard for WordPress.com.

We will now install the required NPM packages to the project:

  1. Type npm install --save react react-dom in the terminal and press enter to install the packages. Using npm to install react and react-dom. Since we are building the theme as a Single Page Application (SPA), we need the help of a tool such as Webpack. We will be writing code as different components, and Webpack will help us package them all together and output them as a single .js or .css file. In short, it’s a module bundler.

    Webpack has first to be installed globally on your computer. To do that, we again can utilize NPM.
  2. Type in the command npm install -g webpack to get the latest stable version of Webpack installed globally in your system.

    Next, we will install NPM packages supporting Webpack in our app.
  3. Go to the package.json file in my git repo and copy the rest of the dependencies from there into your package.json’s dependencies section. Then run npm install again to install all the packages within package.json. { "name": "celestial", "version": "1.0.0", "description": "A basic theme using the WordPress REST API and React", "main": "index.js", "dependencies": { "babel-core": "^6.26.0", "babel-loader": "^7.1.2", "babel-preset-es2015": "^6.24.1", "babel-preset-react": "^6.24.1", "css-loader": "^0.28.7", "extract-text-webpack-plugin": "^3.0.1", "file-loader": "^1.1.5", "image-webpack-loader": "^3.4.2", "node-sass": "^4.5.3", "path": "^0.12.7", "react": "^16.0.0", "react-dom": "^16.0.0", "react-router-dom": "^4.2.2", "sass-loader": "^6.0.6", "style-loader": "^0.19.0", "url-loader": "^0.6.2", "webpack": "^3.6.0" }, "devDependencies": {}, "scripts": { "build": "webpack", "watch": "webpack --watch" }, "keywords": [ "blog", "decoupled", "react", "rest-api" ], "author": "Muhammad Muhsin", "license": "GPL-3.0" }
    The above is a list of all required packages in the package.json file for this project.
  4. Copy the configurations from GitHub and paste it into your theme folder’s webpack.config.js file. var ExtractTextPlugin = require("extract-text-webpack-plugin"); var path = require('path'); module.exports = { entry: { app: './src/index.jsx' }, output: { path: path.resolve(__dirname, 'dist'), filename: '[name].js' }, module: { rules: [ { test: /\.scss$/, use: ExtractTextPlugin.extract({ fallback: 'style-loader', use: ['css-loader','sass-loader'], publicPath: 'dist' }) }, { test: /\.jsx?$/, exclude: /node_modules/, use: 'babel-loader' }, { test: /\.(jpe?g|png|gif|svg)$/i, use: [ 'file-loader?name=[name].[ext]&outputPath=images/&publicPath=http://localhost/celestial/wp-content/themes/celestial/dist/images', 'image-webpack-loader' ] }, { test: /\.(woff2?|svg)$/, loader: 'url-loader?limit=10000&name=fonts/[name].[ext]' }, { test: /\.(ttf|eot)$/, loader: 'file-loader?name=fonts/[name].[ext]' } ] }, resolve: { extensions: ['.js', '.jsx'] }, plugins: [ new ExtractTextPlugin({ filename: "style.css", allChunks: true }) ] }
    Important: Please note that module.exports → module → rules[3] → use → publicPath can change according to where your project’s dist images are situated in localhost. If this is wrong, images may not display correctly in the web app.
  5. Afterwards, these commands can be used to compile the project:
    • webpack or npm run build to compile the project, or
    • webpack --watch or npm run watch to compile the project and watch for changes.

Note: To get a better understanding of Webpack, read this article by Joseph Zimmerman on Smashing Magazine.

Extending The WordPress REST API

The WordPress REST API comes with many different endpoints for fetching posts, pages, media and so on. However, they may not always have all the details in their response. For instance, the posts method does not give the URL of the featured image or the author’s name. Therefore, we have to make separate calls to each of these elements.

Access your WordPress site's data through an easy-to-use HTTP REST API.

But what if you wanted to have your own data appear within the posts response? That’s where the magic of extending the REST API comes in. The following code will add two additional variables in the response to the posts request, namely author_name and featured_image_src. The code is within the functions.php file:

// Add various fields to the JSON output function celestial_register_fields() { // Add Author Name register_rest_field( 'post', 'author_name', array( 'get_callback' => 'celestial_get_author_name', 'update_callback' => null, 'schema' => null ) ); // Add Featured Image register_rest_field( 'post', 'featured_image_src', array( 'get_callback' => 'celestial_get_image_src', 'update_callback' => null, 'schema' => null ) ); // Add Published Date register_rest_field( 'post', 'published_date', array( 'get_callback' => 'celestial_published_date', 'update_callback' => null, 'schema' => null ) ); } add_action( 'rest_api_init', 'celestial_register_fields' ); function celestial_get_author_name( $object, $field_name, $request ) { return get_the_author_meta( 'display_name' ); } function celestial_get_image_src( $object, $field_name, $request ) { if($object[ 'featured_media' ] == 0) { return $object[ 'featured_media' ]; } $feat_img_array = wp_get_attachment_image_src( $object[ 'featured_media' ], 'thumbnail', true ); return $feat_img_array[0]; } function celestial_published_date( $object, $field_name, $request ) { return get_the_time('F j, Y'); }
Extending the REST API with additional variables in the functions.php file.

A Global JavaScript Variable

There are certain WordPress constants (or known as ‘variables’) that we will be using throughout the React app. This will be information about the various routes of the application (and later on be WooCommerce specific ones).

This variable is defined within the functions.php file. It will be called ‘CelestialSettings’ and be appended to celestial-scripts, the handle for the enqueued app.js file:

wp_enqueue_script( 'celestial-script', get_stylesheet_directory_uri() . '/dist/app.js' , array(), '1.0', true ); $url = trailingslashit( home_url() ); $path = trailingslashit( parse_url( $url, PHP_URL_PATH ) ); wp_scripts()->add_data( 'celestial-script', 'data', sprintf( 'var CelestialSettings = %s;', wp_json_encode( array( 'title' => get_bloginfo( 'name', 'display' ), 'path' => $path, 'URL' => array( 'api' => esc_url_raw( get_rest_url( null, '/wp/v2' ) ), 'root' => esc_url_raw( $url ), ), 'woo' => array( 'url' => esc_url_raw( 'https://localhost/celestial/wp-json/wc/v2/' ), 'consumer_key' => 'ck_803bcdcaa73d3a406a0f107041b07ef6217e05b9', 'consumer_secret' => 'cs_c50ba3a77cc88c3bf46ebac49bbc96de3a543f03' ), ) ) ) );
Passing WordPress (PHP) variables to the front-end.

The above code shows an example of getting WordPress (PHP) variables to the front-end, an important and very useful technique when building a decoupled theme. This object variable holds the site title, path, the URL for the API and root and three variables relating to WooCommerce (explained later).

React And JSX

React is different from the rest of the major JavaScript libraries. What I mean by that is, we generally write JavaScript within our HTML. However, when it comes to React, we write HTML inside our JavaScript code. To be more accurate, we write JSX inside JS. JSX is very similar to HTML but has a few differences. The class attribute is written as className for instance. This is then converted to plain JavaScript through Webpack and Babel and saved within app.js.

There are, however, a few restrictions with writing JSX. For instance, we can have only one child within our render() method, which will serve as the root element for a Component. However, the advantage is that it is easier to debug. We can know exactly where we have made a mistake, whereas in normal HTML our error will generally not be shown explicitly. We will be writing JSX for this project, and therefore, the JavaScript files will have an extension of .jsx. However, it could also be .js if you prefer so.

Create the following files within the src folder:

  1. index.jsx (the main file and the one which contains the React Router configurations)
  2. header.jsx (the header component)
  3. footer.jsx (the footer component)
  4. posts.jsx (for the archive of posts)
  5. post-list.jsx (component for an individual post within posts.jsx)
  6. post.jsx (for a single post)
  7. products.jsx (contains all the products from WooCommerce)
  8. product.jsx (displays a single product from WooCommerce)
  9. style.scss (to contain all CSS code in SASS format)
Folder structure of the src folder in the Celestial project. ReactDOM.render()

The index.jsx file is the root of the project. What I mean by that is, the index.jsx contains the component App which is rendered to the DOM.

import { render } from 'react-dom'; // importing render from ReactDOM const App = () => ( // defining the routes <div id="page-inner"> <Header /> <div id="content"> <Switch> <Route exact path={CelestialSettings.path} component={Posts} /> // the root path </Switch> </div> <Footer /> </div> ); // React Router const routes = ( <Router> <Route path="/" component={App} /> </Router> ); render( // rendering to the DOM by replacing #page with the root React component (routes), document.getElementById('page') // rendering the route );

The other components are specified within React Router and will be loaded upon visiting the different routes.

This is how we write modular components where all the different components ultimately end at index.jsx.

Stateful vs. Stateless Components

You would have noticed components being written in either of the following two ways:

  1. const App = () => (
  2. class Post extends React.Component {

The first way is how we write Stateless Components and the second is an example of Stateful Components. Stateless means that component does not have ‘state’ in it. ‘state’ is essentially a variable that has information within the component, and every time the variable changes, the component is re-rendered. Stateful Components are also known as ‘Smart Components.’ The state variables are thus used for inner communication within that component.

The second type, Stateless Components do not have the state variable in them and sometimes called ‘Dumb Components.’ However, like Stateful Components, they have ‘props,’ which are properties passed down to them from their parent components.

Stateful components have the React lifecycle methods whereas the Stateless one has only the render() method which is the default method for it.

React Lifecycle Methods

These are methods called at different stages in the component’s lifecycle, which we can override to run our own code at those instances. We are utilizing the following methods in our application:

  • constructor()
    Called before a component is mounted.
  • componentDidMount()
    Invoked immediately after a component is mounted.
  • render()
    The method which is called to render the JSX (HTML) content.
  • componentDidUpdate()
    Called when the component is updated.
  • componentWillUnmount()
    Invoked when a component is to be removed.

Note: To learn more about Components and their lifecycle, read the documentation here.

Is your pattern library up to date today? Alla Kholmatova has just finished a fully fledged book on Design Systems and how to get them right. With common traps, gotchas and the lessons she learned. Hardcover, eBook. Just sayin'.

Table of Contents → JavaScript Promises

We are going to use JavaScript Promises to get data from our WordPress REST API. First, we have the URL to the REST API in our functions.php, where we have appended it as a JavaScript variable which we can access from the front-end.

We will use JavaScript’s fetch API method to get data from the different endpoints. We are adding a loader to show the user while the content is being fetched:

getMorePosts() { var that = this; var totalPages; // adding a loader jQuery("#loader").addClass("active"); this.setState({ page: this.state.page + 1 }); fetch(CelestialSettings.URL.api + "/posts/?page=" + this.state.page) .then(function (response) { for (var pair of response.headers.entries()) { // getting the total number of pages if (pair[0] == 'x-wp-totalpages') { totalPages = pair[1]; } if (that.state.page >= totalPages) { that.setState({ getPosts: false }) } } if (!response.ok) { throw Error(response.statusText); } return response.json(); }) .then(function (results) { var allPosts = that.state.posts.slice(); results.forEach(function (single) { allPosts.push(single); }) that.setState({ posts: allPosts }); // removing the loader jQuery("#loader").removeClass("active"); }).catch(function (error) { console.log('There has been a problem with your fetch operation: ' + error.message); jQuery("#loader").remove(); }); }
Fetching data from various endpoints, with loader to indicate process is running.

Using The React Router

React Router is the library that will handle client-side routing for our application. Server-side routing is possible with WordPress, but to achieve a truly SPA experience we need the help of React Router.

Since version 4, React Router has been broken into three packages: react-router, react-router-dom, and react-router-native. We will be using react-router-dom for this project since that is the one used in web applications.

Since react-router-dom is installed already, we can write the router configuration inside the index.jsx file. The code will be as follows:

const App = () => ( <div id="page-inner"> <Header /> <div id="content"> <Switch> <Route exact path={CelestialSettings.path} component={Posts} /> <Route exact path={CelestialSettings.path + 'posts/:slug'} component={Post} /> <Route exact path={CelestialSettings.path + 'products'} component={Products} /> <Route exact path={CelestialSettings.path + 'products/:product'} component={Product} /> <Route path="*" component={NotFound} /> </Switch> </div> <Footer /> </div> ); // Routes const routes = ( <Router> <Route path="/" component={App} /> </Router> ); render( (routes), document.getElementById('page') );
Router configuration in the index.jsx file.

The above code will take care of all routing, handled in the client side. The * in the last line says that any other route not mentioned above will take the user to the ‘404 Not Found’ page.

The <Link to=""> tag is used instead of the <a href=””> tag for linking between different pages using React Router:

<div className="navbar-nav"> <Link className="nav-item nav-link active" to={CelestialSettings.path} >Home <span className="sr-only">(current)</span></Link> <Link className="nav-item nav-link" to={CelestialSettings.path + "products/"} >Products</Link> </div>
Using the <Link to=""> tag for linking between different pages.

Getting Test Data

Now that you have created the theme, it is time to add some data. One way of adding data is to create our own content. However, there is an easier (and better) way to add data to our WordPress site. This method imports placeholder data from an external source:

  • Head to https://codex.wordpress.org/Theme_Unit_Test and download the theme unit test data
  • Head over to Tools > Import > WordPress to install the WordPress importer.
  • After the WordPress importer is installed, click on Run Importer.
  • Click ‘Choose file’ in the importer
  • Select the downloaded file and import the WordPress Theme Unit Test Data

Now you have to select the theme-unit-test-data.xml file and all the placeholder content is now on your site.

When all the data is imported correctly. WooCommerce Integration

Now, we are ready to power our store using React. We will use the products.jsx and product.jsx files for this purpose, whose code is similar to posts.jsx and post.jsx respectively.

We will add three more variables to CelestialSettings under ‘woo’ (see A Global JavaScript Variable):

  1. URL
  2. consumer_key
  3. consumer_secret

The Consumer key and Consumer secret have to be generated from DashboardWooCommerceSettingsAPIKeys/Apps.

For the woo URL, you have to manually add it (since WooCommerce allows transfer only over SSL, add the URL with https, i.e. https://localhost/celestial/wp-json/wc/v2/).

Copy the Consumer key and Consumer secret and paste them in the appropriate places within functions.php. This will serve as the authentication for accessing WooCommerce via an API call.

Visit the WooCommerce REST API documentation for more information about its API. The products.jsx file has the code for populating the store with products. The products can be added by an admin from the dashboard. Just go to DashboardProductsAdd New and enter product details.

Add new product via the dashboard.

When you click on a certain product, you will be taken to the product.jsx page:

Individual product page rendered based on the product.jsx file

The code for the above page is similar to post.jsx:

renderProduct() { return ( <div className="card"> <div className="card-body"> <div className="col-sm-4"><img className="product-image" src={this.state.product.images ? this.state.product.images[0].src : null} alt={this.state.product.images ? this.state.product.images[0].alt : null } /></div> <div className="col-sm-8"> <h4 className="card-title">{this.state.product.name}</h4> <p className="card-text"><strike>${this.state.product.regular_price}</strike> <u>${this.state.product.sale_price}</u></p> <p className="card-text"><small className="text-muted">{this.state.product.stock_quantity} in stock</small></p> <p className="card-text">{jQuery(this.state.product.description).text()}</p> </div> </div> </div> ); }
Code for product.jsx file" alt="Code for product.jsx file


For the theme to work correctly, we have to set the following permalinks within DashboardSettingsPermalinks:

  1. Under Common SettingsCustom Structure: http://localhost/celestial/posts/%postname%/

  2. Under Product permalinksCustom base: /products/

If you don’t set the permalinks as above, the theme may not function as desired.

A WooCommerce Fix

When you navigate to localhost/celestial/products, chances are you will get a blank space where the products are supposed to be loaded. This happens because WooCommerce needs authenticated requests whereas our localhost is not https. To fix the issue:

  1. Visit https://localhost/celestial/wp-json/wc/v2/products. This will give us a warning:
WooCommerce requires authenticated requests and will show a warning if localhost is not https
  1. Click on ADVANCED > Proceed to localhost (unsafe).
  2. Now, if you go back to the products page, the items will be displayed correctly.

Note: If you are on Valet on a Mac, you have to run Valet Secure on your site to secure the local site with a TLS certificate. This is another way of fixing the problem.

What Is ScrollMagic?

ScrollMagic is a library that allows us to perform certain actions when scrolling through the page. To use ScrollMagic we will enqueue the ScrollMagic JavaScript library in functions.php. We are using ScrollMagic for two instances in this project:

  1. To lazy-load posts within the posts.jsx component: componentDidMount() { var that = this; window.onbeforeunload = function () { window.scrollTo(0, 0); } // init ScrollMagic Controller that.state.controller = new ScrollMagic.Controller(); // build scene var scene = new ScrollMagic.Scene({ triggerElement: "#colophon", triggerHook: "onEnter" }) .addTo(that.state.controller) .on("enter", function (e) { if (that.state.getPosts && that.getMorePosts !== null) { that.getMorePosts(); } }); }
    Lazy-loading posts within the posts.jsx component
  2. To show a fade-in animation for posts appearing by scrolling through posts and products in the posts.jsx and products.jsx components respectively: componentDidUpdate() { var FadeInController = new ScrollMagic.Controller(); jQuery('.posts-container .col-md-4.card-outer').each(function () { // build a scene var FadeInScene = new ScrollMagic.Scene({ triggerElement: this.children[0], reverse: false, triggerHook: 1 }) .setClassToggle(this, 'fade-in') .addTo(FadeInController); }); }
    Applying a fade-in animation for posts which appear as scrolling occurs

We are now ready to view our theme from the front-end. Navigate to localhost/celestial on your web browser and see your theme in action.

And pat yourself on the back, because you have now successfully created the theme!

Other WordPress Themes With JavaScript Libraries

If you found this helpful, you can take a look at other awesome decoupled WordPress themes built using modern JavaScript libraries/frameworks:

  • Foxhound: The first decoupled theme to make it to the WordPress themes repository. Written by Kelly Dwan, this theme uses React, Redux and React Router.
  • Anadama React: Another theme by the same author, but using Flux instead of Redux, and Page instead of React Router.
  • Wallace: Written by Kirby, this theme uses Angular with the WordPress REST API.
  • Picard: Written by Automattic themselves to showcase the capability of the WordPress REST API.
  • React Verse: A React and Redux theme I wrote based on Foxhound.
Next Steps

The main sections I wanted to show you are now done. You can continue with building the project for further knowledge. These are some recommendations that you could pursue:

  1. A full-fledged store with the WooCommerce plugin, including checkout and shopping cart;
  2. A page each for archive, tag, taxonomy, and so on;
  3. State management with Redux or Flux.

Good luck, and happy coding!

(mc, ra, al, il)
Categories: Web Design

A Comprehensive Guide To User Testing

Smashing Magazine - Wed, 03/07/2018 - 02:30

(This is a sponsored article.) With a prototype of your design built, it’s important to start testing it to see if the assumptions you have made are correct. In this article, the seventh in my ongoing series exploring the user experience design process, I’ll explore the importance of user testing.

As I explored in my earlier article on research, where I explored the research landscape, there are many different types of research methods you can use, and there are a variety of different user tests you can run, including:

  • Usability Testing
  • Eye Tracking
  • Interviews and Focus Groups

In this article, I’ll be focusing on usability testing, where we evaluate the design decisions we have made against a representative set of users to test if our assumptions are correct.

With your prototype in hand, you might be all set to go with the final build of your website or application, but it’s important to pause and undertake some testing at this stage in the process. Getting some typical users in front of your design is critical so you can get a feel for what works and — equally — what doesn’t.

Similarly, when you’ve undertaken your final build, you might be forgiven for thinking that everything is finished. In fact, once you’ve launched, you’re only at the start of the journey. Ideally, you’ll undertake some further testing and, with your findings from that testing in hand, revisit your design and address any issues you might have discovered.

Remember: Design is an iterative process. There are always improvements to be made, informed by your testing.

In short: User testing should be happening at every point in the process as an integral part of an iterative design process. With that thought in mind, it’s important to establish a structured framework for user testing throughout the design process:

  • Before you undertake your initial design, perhaps using paper prototypes;
  • During the digital prototyping phase, using lo-fi and hi-fi clickable prototypes; and
  • At the end of the process, helping you to refine what you’ve built.

You might not have the budget to run fully-fledged usability tests, and for many projects that’s understandable, but that doesn’t mean you shouldn’t at the very least test your designs informally. Guerilla testing — ad-hoc testing with passers-by, run in an informal manner — is better than no testing.

The bottom line? Any testing you can do — no matter how informal — will serve you well. With the importance of usability testing underlined, let’s explore the why and when of testing, stress the importance of good preparation, and dive into running usability tests effectively.

Usability Testing: Why And When?

First things first, to run an effective usability test you don’t need formal ‘laboratory conditions.’ It’s far better to run some usability testing using what you have to hand than to run no usability testing at all.

You might be wondering, why bother? Usability testing takes time and — when you’re under pressure and with deadlines looming — you might be tempted to forego it. Don’t make this mistake: it will cost you more in the long run. Usability testing will, of course, require a degree of investment in time and money, but it will more than pay off.

Your goal is to gather as much feedback as you possibly can as early as you possibly can. This helps you to identify any design issues before you get to the expensive part of the process when you reach the final build. It’s too late — and too expensive — to leave user testing until after you’ve built your product. At that point in the process, changes are incredibly costly.

As I noted in my previous article on wireframing and prototyping, the earlier you identify problems, the less expensive they are to fix. Running a usability test will, amongst other things, help you to:

  • Identify if users are able to complete specific tasks successfully;
  • Establish how efficiently users can undertake predetermined tasks; and
  • Pinpoint changes to the design that might need to be made to address any shortcomings to improve performance.

In addition to these objective findings:

  • Does the product work effectively?
  • Running a usability test helps you to make subjective findings: Do users enjoy using the product?

These objective and subjective findings provide valuable feedback that help you to shape and improve your design.

With the benefits of running usability tests clearly established, let’s explore when in the design process you should run your tests. There are a number of points in the design process that you might run usability testing. You might be testing an existing product or a competitors’; this will depend on your project and its circumstances. You might, for example, be:

  • Testing an existing product you’ve created that you plan to redesign;
  • Testing competitors’ products so that you can learn from them if you’re moving into a space where there is already an existing, competing product; or
  • Testing a product you’re currently in the process of working on.

It’s important to allow for more than one series of usability tests. Ideally, you’ll be testing at multiple points in the process: at a midway point with some clickable prototypes; and once your final build is done and you have a fully built product.

Ideally, usability testing should happen throughout the design process. At the prototyping stage, it can help identify issues that would be expensive to fix later in the process. At the final build stage it can equally identify issues that might have been hard to replicate at the prototyping stage.

Each of these points in the process offers you something different to learn and helps you address shortcomings in your assumptions before your final build. The rule of thumb is: The earlier you run a usability test, the better.

Like anything, the better prepared you are, the more effectively your usability testing is likely to be, so let’s explore the importance of preparation.

Preparation Is Key

To run a usability test effectively will take between 30–60 minutes per participant. Of course, depending upon the complexity of what you’re building, this length of time will vary, but in my experience, an hour is about the maximum time I’d recommend.

The longer a usability test runs, the more tiring it is for the participant, leading to diminishing returns. As such, preparation is key. It’s important to establish upfront exactly what you hope to learn from the test and, equally importantly establish who you’ll be testing. To do this, it helps to:

  • Develop a solid test plan that outlines your usability test, ensuring that when you test across different individuals, you’re doing so in a consistent manner; and
  • Establish clear criteria for recruiting participants, so that you’re testing users who are appropriate to what you’re designing.

The preparation you put in place before the test will pay off in terms of efficiency and improved findings. Bear in mind that running a test will require a number of individuals:

  • The test participants;
  • A facilitator, guiding the test and ensuring everything runs smoothly; and
  • Some observers and note takers.

Time is money, and with so many people involved in the process, it’s important to ensure that the time you’re investing pays off. To remain focused it’s important to establish a plan for your usability test and prepare a script that ensures everything is consistent.

Establishing A Plan

Your plan serves to establish the following: what you plan to test; how you plan to run the test; how you will measure what you’ll capture and what metrics you’ll use; the number of users you’ll test; and what scenarios you’ll use as the backbone for the test.

Think about the scenarios that you are trying to test. What is your website or application’s purpose? What’s its primary goal? It’s important to establish a plan around this, including the following elements.

Where and when?

Where and when will you be running the test? Unless you’re working for a large organization, it’s unlikely you’ll have a dedicated space for usability testing. That’s fine; the important thing is you’re running some usability tests!

Try to find a quiet space that you can welcome your test participants and make them feel at ease. Also allow for space for a facilitator, who will run the test, and some observers, who will take notes. It helps to group your usability tests so that you can cross-reference your findings across users while everything’s fresh in your mind.


Establishing the scope of your usability test ensures your goals are realistic. You might be designing a website or a product that is large in scope, but when defining the scope for your usability testing, be realistic. You only have so much time, so focus on the important aspects that you need to address.

Specify what you’ll be testing, for example, your website or application’s navigation system, or its e-commerce flow. This will keep you focused and ensure you don’t drift off-topic.

If you’re dealing with a complex piece of design with multiple moving parts, you might want to run a series of different usability tests; each focused on a particular aspect.


Different usability tests will require different timings, but as a rule of thumb, it helps to allocate around 30–60 minutes per participant. Moving beyond an hour can result in participants getting tired, which — in my experience — leads to a drop-off in the quality of feedback.

When scheduling your usability tests ensure you allow for sufficient time between tests. It’s important to allow for discussion amongst the team immediately following a test, while the test is fresh in everyone’s mind. Equally, a buffer between tests is helpful in case a test runs over or a participant arrives late.


Again, the equipment you use doesn’t have to be overly complicated. It’s important to be able to capture the session in some form, ideally using video. Above all, it helps to be able to capture what users’ say and their expressions. As I’ll explore in a moment, you can tell a lot about a design by looking at a test participant’s reactions. Their facial expressions and body language will often tell you as much, if not more, than what they actually say.

We’re fortunate now to have low-cost screen recording software at our disposal. Screen recording tools like Screenflow are very cost effective and, using your computer’s built-in webcam, enabling you to capture not only what the user is doing on screen, but also the look on their face.

With your plan clearly established, it’s time to develop a script.

Creating A Script

Building on your plan, your script will help you to facilitate the usability test clearly and consistently. Creating a script helps you to:

  • Focus your mind on what exactly you’re testing, so that your usability test doesn’t drift and remains focused;
  • Ensure consistency across multiple test participants;
  • Talk about different user scenarios;
  • Clearly, articulate the different goals you’re testing; and
  • Help you put your users’ minds at ease.

It helps to break the script down into a couple of sections: a section that acts as a preamble, and a section that covers the main body of the test itself.

Your preamble is designed to settle the user before the test starts. In it, you cover what you’re testing and why you’re testing it. Above all, it’s important to ensure that you put the users’ mind at rest, assuring them that you are not testing them, you are testing the product.

Participants are human beings, and it’s only natural that they will apologize if and when things go wrong. You need to put their minds at ease and assure them that nothing they do or say is wrong.

Your script is designed to focus your test on the scenarios you have established in your plan. When establishing your scenarios, bear in mind that — depending upon the complexity of the website or product you’re building — you will only have a limited amount of time to test everything, so be realistic.

It helps to establish a story around which you build your series of tasks. For example, if you’re testing a travel-related website or application, consider:

  • How many people are making the journey?
  • When are they traveling and do they have flexibility with their dates?
  • What kind of budget do they have?

Of course, every scenario will be different. The bottom line is to spend some time defining what exactly you plan to test so that your testing is focused on testing the right thing and returns valuable results. If you’ve spent some time building user personas for your project, you might like to build scenarios around these.

In short, try and create as realistic a scenario as possible. As websites and applications become increasingly complex, it helps to test user journeys through your interface. This also helps to tie your testing back to the user stories you identified earlier in the design process, which I explored in my previous article on high-level UX design.

Recruiting Participants

With your plan ready and your script written you need to identify some participants to undertake your usability test. As with your plan and your script, preparation is key; it’s important to put some thought into identifying the right participants.

There’s no point setting aside a considerable amount of time to undertake usability testing and then testing random strangers. Spend some time to identify and find the right kind of people for your test.

First things first, it’s important to test more than one person. Everyone is different, and everyone draws from different experience, so ensure that you’re testing a variety of different people, so your results aren’t skewed by too small a sample size. What you’re designing will affect who you choose, different websites and products attract different audiences, so plan accordingly.

Usability.gov has an excellent Usability Test Screener that is a great starting point for building your own screener.

It helps to establish a profile and create a screener to help you identify candidates so that you recruit participants who accurately represent your potential users. It’s important that your participants share the characteristics of your typical customers; again, user personas will be helpful in identifying these characteristics.

Imagine you’re building a mobile application for a new digital challenger bank aimed at a younger demographic, your screener might include the following:

  • What gender do you identify as?
  • What age are you?
  • Which bracket does your income fall into?
  • Are you a saver or a spender?
  • Does your current bank have an app and do you use it?

It’s important to ensure that your questions are inclusive. Equally, exercise some discretion when asking sensitive personal questions. For example, when asking for income — if it is relevant to your test — provide brackets for income so that you respect your applicants’ confidentiality.

If you’re looking for a good starting point, Usability.gov have an excellent example of a Usability Test Screener for website testing. This is a useful starting point and will give you some ideas.

With a plan created, your script in hand and some participants lined up it’s time to run your test, so let’s explore that now.

Running The Test

Before you begin your usability testing it’s important to get everything organized and in place. It helps to have a record of each usability test you run, so that you can look back through it later and undertake some analysis. This might be through screen-recording software alone, or it might include recording a video of the test.

If you’re recording the test, it’s important to ask your participants for permission. Equally, this gives you an opportunity to explain why you’re recording the session and what you’ll be using the recordings for.

Remember, your goal is to put your participants’ minds at ease, and explaining what’s what helps to do this before you start the test.

Before The Test

Rather than diving straight into your testing scenarios, it helps to run through a short preamble, explaining what it exactly as you’re trying to achieve through your testing. This ensures you give your participant a clear idea of what you’re expecting of them, helps to take the pressure off them, and eases them into the test.

It’s helpful to outline who’s in the room and why, explaining that while you’re running the test, the others present will be recording their observations. It also helps to give the participant an idea of how long the test will last and, broadly, what you’ll be covering.

Before you begin, it’s important to inform the participant that you’re not testing them, you’re testing the software and that there are no wrong answers. The participant needs to know that your intention is to watch them using what you’ve built and, to ensure the conditions are as real as possible, you won’t be offering them advice.

This last point is critical, especially of you’re running a usability test on something you’ve designed. It’s important not to interrupt the test participant’s flow by offering them guidance and advice. You won’t be there to do this in the ‘real world,’ so resist the urge to offer advice from the sidelines.

Even if what you’re testing was designed by you, it’s important that you don’t tell your test participant. (A little white lie won’t hurt!) You’re dealing with humans, and if your test participants know that they’re giving you feedback on something you designed, they are likely — only naturally — to hold back on their criticisms. No one likes to hurt someone’s feelings, and it’s important you get an honest opinion, so don’t skew the participants’ answers by telling them they are judging something you designed.

Ask your test participants to try, if possible, to verbalize what they think will happen as they work their way through the scenarios. This helps you to get a feel for what they’re thinking. It also helps your observers and notetakers if you ask your participant to run through the tasks you’ve set them a little more slowly than they might if this wasn’t a test.

As a facilitator — from time to time and being careful not to interrupt the flow — you might like to ask the participant what they think might happen next before they undertake a particular action. This helps you measure your user’s mental model of what’s happening to see if it aligns with the mental model of the design.

Lastly, stress that if something goes wrong during the test, it’s the software’s fault, not the user’s. It’s important that your test participants don’t think something is ‘their fault’ when it’s an issue with your design.

During The Test

With your preamble done, it’s time to get the test underway. As you walk your participants through your script setting them various tasks, it’s important to resist the urge to lead them. Your goal is to see how they react to the tasks, helping them out with advice defeats that purpose.

This can be incredibly difficult, especially if you’re testing something you’ve designed, but you need to do your absolute best not to try and help out. It can be frustrating watching someone struggle to understand how to use something you’ve built — that you think makes absolute sense — but remember, what you’re discovering is helping you.

Equally, if you’re responsible for the design try not to let your facial expressions give the game away. This takes practice (especially for me!), but it’s important that you try and remain as neutral as possible.

When running your usability test, you’re learning on two levels, by:

  1. Listening to what people say; and
  2. Observing what people do.

Listening and observing are both important and will provide you with different insights. Listening will give you subjective feedback on your design: “I like this because…,” “I like this kind of feature…,” “I prefer it when….” While subjective, and dependent upon your test participants’ opinions, this kind of feedback is useful, because it can surface ways of doing things that you may not have considered.

Observing how your test participants use your website or application is a great way of seeing what works and what doesn’t. Again, you’re testing your assumptions: you think you’ve designed something that’s perfect, but sometimes your test tells you otherwise.

It’s important to be aware of the distinction between listening to what people say and observing what they do. You are dealing with human beings when you’re running a test and humans like to consider others’ opinions.

You might run into situations where someone you’re testing is complimentary about a particular design or feature (“I like this.”), yet their actions tell a different story (you watch them desperately trying to complete a task you’ve set them!).

Don’t underestimate the power of observation. As Yogi Berra famously put it:

"You can observe a lot just by watching."

This is why, when you run a test it’s important to have more than one person involved. You’ll need a facilitator to take the participant through the usability test, using the script as a guide; and one or more observers to capture the participants’ reactions.

In Closing

Testing — and particularly usability testing — is a critical part of the design process. Run them well; an effective usability test will save you money in the long run. Running usability tests, ideally at multiple points in the design process, helps to keep your users positioned front and center, which — as user experience designers — is our goal.

Your tests don’t need to be run in fully fledged laboratory conditions; the important thing is you’re undertaking testing. If you’re on a shoestring budget, some guerilla testing is better than no testing; just ensure that you’re testing on the right kind of person.

Remember: Who you test is important. There’s no point putting in the hard work to build a detailed usability testing plan if you’re testing the wrong people.

Lastly, as I noted in my article on user research it’s important to spend some time analyzing your research findings. When you’ve completed a number of usability tests with different participants, sit down with your team, cross-reference everything, and look for patterns of behavior.

Identifying pain points — points in the process where your participants ran into difficulty — means you can fix those pain points. Equally, identifying moments of delight can help you identify what you might want to do more of. Taken together, this feedback — once you’ve applied it — will lead to a better experience all-round.

Suggested Reading

There are many great publications, offline and online, that will help you on your adventure. I’ve included a few below to start you on your journey.

This article is part of the UX design series sponsored by Adobe. Adobe XD is made for a fast and fluid UX design process, as it lets you go from idea to prototype faster. Design, prototype, and share — all in one app. You can check out more inspiring projects created with Adobe XD on Behance, and also sign up for the Adobe experience design newsletter to stay updated and informed on the latest trends and insights for UX/UI design.

(ra, il)
Categories: Web Design

A Comprehensive Website Planning Guide (Part 3)

Smashing Magazine - Tue, 03/06/2018 - 03:40

In Part 2, I covered the details of evaluating a plan, choosing web professionals, and determining your website structure. The question of why planning for the web is just as important as planning for anything else associated with your business was covered in Part 1, so head on back to read that part first in case you missed it. In today's final part of this guide, I'll start with a few of the most common approaches in any initial design.

Initial Design: Three Common Approaches

There are, of course, others, including hybrids which combine elements of each, and every design team and every project is different, but there are core approaches to creating a web design.

1. Classic Photoshop mockup approach

Commonly created in Adobe Photoshop (the industry standard) or other design software such as Sketch, the initial design will consist of a visually accurate image ("mockup") of the home page and at least one internal page.

Your business' visual branding elements should be applied here. If you have well-defined graphics in addition to your logo, they will dictate the design of the site. However, if your brand lacks detail, the designer will do their best to create work that accurately reflects the business, working with your existing graphics as a jumping off point.

Following is a short list of key points for successful mockups. We'll assume the designer is working in Photoshop, however, these guidelines also apply to other design programs.

  • Start with a pre-made grid with pre-drawn, pixel-accurate guides. Some designers create their own, while others may adhere to a pre-set grid system. Whatever the case, it's important to have a clean template to start. Make your canvas wider than the width you're designing to, so you can add notes on one side and get a feel for what the site feels like when floating in a wide browser window.
  • Add the color palette and basic branding elements (i.e., fonts) in the margins of the canvas so you'll have it for reference when viewing on screen or in print.
  • Draw everything to exact pixels, and draw clear guides and/or slices around design elements. This becomes critical when the front end developer later creates the HTML from the mockup, however, your design will only be pixel-accurate when displayed on a ‘big screen' device.
  • Organize all design elements with a logical folder/subfolder structure, and label each item clearly.
  • If the designer will be handing off their files to an HTML developer, this is especially important. Name your folders and layers for their content so there's no confusion later. For example: "Sidebar — events header" is clear, "Layer14 Copy Copy Copy" is not.

Getting the process just right ain't an easy task. That's why we've set up 'this-is-how-I-work'-sessions — with smart cookies sharing what works really well for them. A part of the Smashing Membership, of course.

Explore features →
  • Make clear notes dictating fonts, alignment, repeating background elements, gradients and anything that will need to be implemented with CSS techniques. In Photoshop, the sticky note feature is good for this. If unclear, ask the person who will be converting your design into a working page.
  • If using a common style for headers, navigation, or other design elements that appear throughout the site, consider making separate Photoshop documents for them. Some designers find it easier to "chunk it down", especially in big projects.
  • Use realistic content. Designers often use greeking ("lorem ipsum") to fill space, which is ok for body copy. However, for headlines, titles, events, etc., try to use realistic copy. Consider the two following headlines. Layout considerations are different for each:
    • "Widgets, Inc. Wins Green Manufacturing Award"
    • "Widgets, Inc. Employees Win Landmark Court Case Affirming Employee Right To Petition For College Tuition Reimbursement When Training Is Relevant To Work Role"
Large preview The problem with this method

When you design pixel-perfect mockups, you can be assured that the website's appearance will be very close on the desktop web — but that's it. The minute you switch to a different device, it will change. So at the very least, you'll want to either convey to the business how the design will change as it is viewed on smaller screens (tablet, smartphone) by showing a site with similar layout, or design additional mockups at common screen sizes. As you can imagine, this is a lot of additional design work, and if you change an element on the desktop-focused mockup, you'll have to change it on the others too. Here's the smartphone view.

Large preview 2. Design in the browser

With the rise of responsive web design, some designers are moving away from the Photoshop mockup approach, instead using responsive frameworks like Bootstrap or Foundation, or tools like Froont or Typecast. These tools allow very rapid, iterative design that allows you to see how the site will look on different devices.

You may still use Photoshop or other graphic design tools to create stylized elements to place within the design, but the bulk of the design will happen outside these tools. There is no good way to show the business "exactly what it will look like" so for designers used to making pixel-perfect mockups for the desktop web, in-browser design may not be the best approach. For many, this method also represents a major change to their process and can take a while to get the hang of. Most see this as a necessary evolution, since a Photoshop mockup can only represent one of the many "frames" in which your site's content is displayed, and the world of web is moving rapidly toward designing for multiple platforms from the get go.

When it's time to write the HTML, CSS and Javascript that will make up the site, you can either stick with the framework you used initially to create your design iterations, adapt its code, or write your own from scratch, using your framework designs as a guide.

3.Element collage (also know as style tile, style collage)

With this approach, the designer will assemble a range of elements that make up a website including header, navigation, icons, sample photography, illustrations, forms, interactive elements, and anything else deemed necessary to get a good sense of the site's look and feel. Additionally, depending on the design tool, these elements may be laid out in such a way as to show how their appearance will change in unison with the screen size. This is typically combined with some kind of graphic mockup of at least the home page and few internal pages. (It can be hard for businesses to visualize how pages in a site will look based solely on an element collage.)

Note: These sample images are not to scale — our Photoshop version of the element collage is one long page, 1500X4500 pixels, so we can't fit it here in one piece.

Large preview

For designers (and businesses) long used to the Photoshop mockup method, this is also a new frontier, and requires a change in perspective. With a style prototype, you're not trying to layout a page exactly, but rather, to show the key parts of the site and get feedback on the general look and feel. Because a responsive site must change in appearance radically as the screen size changes, this method is much more about about the parts of a site and getting a feel for the direction the design is heading. You're not showing the site as a whole, let alone making a pixel-perfect representation of exactly how each and every page will look.

This can save a lot of time, but again, if the business isn't comfortable (or trusting) enough to let the designer make structural decisions later on down the line, this method may be a tough sell. That said, it really can create a flexible environment in which to rapidly create web designs for myriad platforms.

While the principles of graphic design are timeless, the approaches used for website design will change and evolve over time. I highly recommend you watch Design Deliverables for a Post-Comp era to discover the value of this approach.

When using this the element collage method, the business must accept there is no exact, precise, final draft of a given page, only layout guidelines to agree upon. The very nature of responsive sites is to adapt their content to the capabilities of each device, so the businessmust not expect to approve set-in-stone layouts prior to the development phase. With an approved style prototype, a designer may want to return to wireframes or working prototype to work out all the layouts your project requires. Then when it comes to build the site, you will assemble the elements of your collage into the visual structure of each unique layout.

There is much discussion and debate in the design community about the best tools, methods, and process for creating web designs. Designers tend to feel very strongly about which is the "best" method, and while that's understandable, it's important to use the most suitable process for the project and the business. It's smart for designers to get comfortable working with an array of methods and systems, and broaden their horizons when a project allows.

Author's note
I was very hesitant to include some of the following content, because it highlights serious tensions in the business-designer relationship. While it may seem overly critical of business owners, I believe it is of great value to businesses because so much time and money is at risk in a website project.
In the interest of diplomacy and preserving client relationships, designers probably won't voice these frustrations to business owners, but the following issues can and do derail projects. Design approval and revisions

Regardless of which design method was chosen for the project, when the design is complete, the results are are shared with the business for approval, and there is often a (hopefully short) revision process. The revision process involves the the designer and key stakeholders going back and forth a few times, trying different edits to the design until the design is approved.

Design by committee: don't do it.

A common (and completely avoidable) problem at this stage is the consideration of too many opinions, simply having too many cooks in the digital kitchen.

To help ensure a smooth process, the business must assign one person as the point of contact for the design team. That person is responsible both for communicating with the designer and for making final decisions about design direction.

Certainly, it is important to solicit feedback on design, and project stakeholders have valuable critique to offer, helping guide the design process so that the end result accurately represents their business.

Additionally, in some instances, review by legal and/or technical staff is needed. However, having the entire company offer input, and lending equal weight to all feedback leads quickly to nobody being satisfied. The best possible way to ensure a muddy, unfocused design is to give everybody input and then to run around making all the changes proposed.

Generally speaking, in small businesses or organizations, having any more than five people provide design feedback is a recipe for gridlock. The fewer the better, five is the maximum. These five (or fewer) people will solicit feedback from their subordinates or department colleagues, but that input should be compiled by each stakeholder and presented as a unified, single opinion. In other words, don't invite fifteen people to a design review meeting. Weed out all the back and forth before you go to the designer with input. It's also very important to distinguish between objective design concerns ("does this color scheme really suit our bakery?") versus personal design preferences ("I love the color blue — let's use a lot more blue").

Design is not an arbitrary pursuit. There is good design and bad. There are rules to be followed, best practices to be adhered to, and as long as planning has been done properly, design decisions are almost never really a matter of taste. That is, there's a good reason the designer used that exact blue, in that exact spot, or that font at that size. All of those little choices communicate things to the user. They may feel insignificant, but in reality, all these choices the designer makes are important. They can drastically affect the way the site functions and how it is received. Unfortunately, many businesses fail to understand that just because they like it doesn't mean everybody else will, and doing what's best for conveying the soul of the business is what the designer is hired to do. Opinion shouldn't enter into it unless absolutely necessary.

When egos rule

Any experienced designer has dealt with decision makers who have the dreadful combination of strong ego and poor design sensibility. In the worst case, designers will be asked to use a logo the CEO developed in Microsoft PowerPoint, or colors and fonts totally unsuited to the business' image. This, unfortunately, comes with the territory of being a designer. Sometimes it's possible to diffuse this by placing the offending artwork in a grid alongside professionally designed material from competitors or similar companies in the industry — Pinterest is a good tool for this.

If a competitive review was part of your needs assessment, you may want to refer to their brands for reference. The hope is that the business can see how awful their version looks next to the competition and rethink their commitment to the bad idea. Ultimately, however, decision makers can and do ruin projects by insisting, contrary to all available evidence, that their design sense should take priority over established design principles.

Help! They won't budge!

Readers of an earlier version of this book asked for ways to deal with the ego problem. I wish I had a clever or useful answer for you. Suffice to say this is a problem with people, not technology. Make your best case for the value of good design, fight your best fight, then be prepared to let it rest.

Design tension: designer vs. the business

Designers often deal with tension between their informed concepts of design and business' uninformed design critiques. This is best illustrated by the "bad idea" conundrum. The business will request a design feature that's either ugly, unworkable, or just a bad idea. (This is so common that there are many websites which chronicle clueless businesses and the headaches that result in this dynamic1.) The designer will respond somewhere on the continuum between "that's horrible, we won't do it" and "well, if that's what you prefer...". This response is dependent on a variety of ever-shifting factors, including:

1http://clientsfromhell.net, http://theoatmeal.com/comics/design_hell

  • When designer hopes to get paid.
  • How emotionally invested designer is in the project.
  • How much time the designer has invested in the design phase, and how much delay will result from implementing the bad idea.
  • How high the stakes are — how much damage the bad idea will do to the site as a whole.
  • Personality, businesses' willingness to take constructive counsel about their ideas.

Every project is different. When designers deal with businesses who continually request features that are ill- advised, at some point they may write off the project altogether. At a certain point, it's just too exhausting to continually explain why centered, bold paragraphs in red, WRITING IN ALL UPPERCASE, crazy Flash animations or poor quality photography make an ineffective website2. The designer's attitude rapidly shifts from "let's make something really great that we're proud of" to "let's just get it done so we never have to look at this again."

2Other mood killers include autoplay videos and fonts most often used in children's books.

While considering the above, also realize that there's another side to this coin. People problems can also crop up on the designer end of the spectrum. Some designers' skills may not be up to par, they may refuse to listen to valid criticism of their work, or may not value the informed input of the business. A good way to avoid this is by getting good references from designers' past clients.

Consider the content

Think about expansion. For example, you may have a news section. To start, you have six news items. That's fine. You'll make a main news page with summaries and link the summaries to a detail page. But what happens when you have ten, twenty, or fifty news pieces? Now there are other considerations. Do you want to archive old news? Create pagination? Only show the most recent ten items? This should be considered in the design process. Plan around content as much as possible in the design process, and think ahead wherever you can — plan for the content you will have, not the content you have right now.

Web style guide

A style guide is where proper planning shines. A style guide will consist of all the design, layout, interactive (i.e. JavaScript) and type elements used throughout the site in one location. This is usually done in HTML, so if you're a designer who doesn't code, you'll need to create a mockup for your style guide and deliver it to your front end developer along with the rest of your designs. If you've used the element collage method covered earlier, you may not need to repeat yourself in a separate web style guide. If you're using the classic Photoshop mockup method, you will need one. Elements of a style guide include, but are not limited to:

  • Navigation styles
  • <h1> through <h5>, also known as header tags
  • Paragraphs
  • Lists
  • Block quotes
  • Italics, bold face, underlines
  • Links, including active, hover and visited states, that is, the appearance of links, including when hovered over with the mouse
  • Icons
  • Use of images and image style
  • Use of background images or "watermarks"
  • Forms.

This article from Canva explores 10 web style guides for well known companies. You can also use an online tool like Frontify.

Using A Pattern Library

For websites of larger scope, you might expand the web style concept to the more robust pattern library, which explains how various elements appear and how they are handled. Sample code for these elements is usually part of the library. It's not just a picture of it, but the thing itself. For example, what does a form look like, what happens visually when it has errors, what is the process for comment submission, etc.

Approved mockups, element collage and wireframes, along with the style guide, are used as the building blocks for the next steps of development.

HTML/CSS Creation

Using the designs and style guide, an HTML/CSS expert (the front end Coder) will create HTML templates which accurately represent the design as approved. In some cases, templates will appear identical to mockups, however, where Photoshop was used for mockups, subtle differences are to be expected.

Your front end coder might also need additional guidelines and assets related to designs, like color palettes, specific images, icons, and — if not explicitly noted already — design rules like margins and padding. Make sure you know what all the deliverables will be before you start sending files. If designs and style guide were created with plenty of attention to detail, there should be few questions or guesswork at this stage; work should be humming along.

Interactive Element Creation

Interactive elements may be as simple as a drop-down menu, or as elaborate as a pie chart creator. These elements are typically developed with JavaScript, often using a script library like jQuery. At the most general level, this consists of assembling (and writing) a set of instructions that interact with pages on your website. There may be interactivity between site and server to consider too. You might be connecting APIs3, making something like a booking or calendar system etc., or using widgets from third party services.

3 Essentially, a bridge between one or more systems. For example, Facebook offers an API that allows you to pull in posts from your wall to an unrelated website.

 CMS Integration

At long last your brilliant design has been converted to code and is ready to be integrated in a Content Management System (CMS). It's well on its way to becoming a website!

The individual or team tasked with doing the "stitching" of the code to the CMS will provide you with a login for the control panel of the CMS, which allows you to enter the content, including text, photos, videos, and documents. Most writers prefer to cut and paste from Microsoft Word.

Depending on the specifics of the CMS selected, you may be able to do this without issue, retaining simple formatting like bold, italics, and lists. However, the CMS may strip out this formatting when you cut and paste, requiring you to add it back. While sometimes tedious, this insures your content remains neat and orderly, which makes it more easily indexed by search engines, more easily printed, cited and converted to other formats.

Although in reality this process is quite involved, I've left out the details because the exact process will be unique to each CMS, and doing this well relies on the expertise of the Web/CMS Developer.

Training And Documentation

While modern CMS can be very user friendly, it's important to coordinate training for the people responsible for entering content. When possible, on-site training is best, with web conference a second choice. Training works best in very small groups — 5 people or less. Additionally, having people actually follow the steps needed to complete a task on their own, (rather than just having them watch the trainer and try to remember how to do it when they're on their own) is much more effective.

Training should be supported by documentation, which can take many forms:

  • Step-by-step video ("screencast")
  • PDFs with screenshots
  • Printed guidelines
  • Contextual help (built in to the CMS).

Sometimes documentation combines some or all of the above. Whatever you choose, keep in mind the skill level of the people entering content. Many people who work in offices are competent at Microsoft Word and email, but can be challenged by basic but necessary "design" tasks like sizing and cropping images. Also remember that the business probably isn't working with the same set of professional design tools that the designer is, so make allowances for the business' technological concerns as well.

It's a good idea to save the writing of documentation until as close to the end of the project as possible. Remember that if you change something in the CMS mid-project, you may have to update documentation to match. This can be very time-consuming (and confusing too), so try to coordinate the parts of your project so the documentation is written once the content entry process has been finalized.

Puttin' it all together...

At this point, having followed the preceding steps, you should now be sitting on a pretty solid website. Regardless the size of your project, now is a good time to:

Review your content once again, checking it against the points listed under writing for the web above.

Ask a third party to proofread all your content. This is not the task of the designer or the original writer. It's best to bring in someone with a fresh perspective. Don't proofread your own work.


When you feel your website is almost ready for the public to see, it's time for beta testing — a process of going through all aspects of the site, making sure everything appears and functions as intended. Consider this checklist, at minimum:

  • Does the site look as intended in all targeted web browsers? Web browsers include the usual Internet Explorer, Firefox, Safari and Chrome, as well as those that come with common mobile devices. If you've been viewing the site on a desktop browser up until now, you may find unexpected glitches when you switch to a tablet or smartphone. This is the time to thoroughly review your site on a variety of devices before it can be considered ready for public consumption. Remember — your site's audience will use a wide range of devices to view your site, and it needs to work acceptably well on all of them. You don't have to physically test your site on every possible phone or tablet, but you should try it on a handful of common devices. Don't go out and buy a five-year-old Blackberry for testing purposes.
    "Emulation" websites and services like Spoon.net will generate previews of your site on just about every browser or device known to humankind, giving you a good idea of how it will look in most scenarios.
  • Interactive features work smoothly.
  • Contact or other forms work predictably and generate the correct response to the user and recipient of the information submitted.
  • Error messages are helpful and human-friendly.
  • Internal and external links function.
  • Images are sized properly.
  • All placeholder content has been replaced by the final copy/images, etc.
  • Internal and external links, including email links, work properly.
  • Integrations with third party software, such as email service providers, are working.

At this point its very wise to enlist someone who has had no involvement in the process to date, and ask them to methodically go through each page and feature in the site, noting any errors or glitches they find. Don't use someone who's been staring at the site for months. Problems to look out for could include typos, bad links, image sizing, failures on specific mobile devices, or content that's missing or incomplete. (Make sure to tell your tester that the design of the site is set in stone at this point, so they're not wasting time looking at non-content considerations.)

Pre-launch coordination

When you approach launch time, you'll need to coordinate with your company's other marketing efforts. If you're active on social media, write and proofread the announcement of your new/redesigned site, and set a schedule to post the announcement. Prepare to update your outgoing voicemail message and coordinate print advertising — everything needed to support the launch of the site.

Redirecting traffic from the "old" site

If your new website is replacing a previous version, it will probably have a different URL structure, and you need to map the old structure to the new. There are two reasons to do this. First, search engines have indexed the URLs of your old site. This indexing has a lot of value to people searching for what your company offers. When you launch a new site with different URLs, the old ones will break and users will get a "page not found" message (404 Error). You want to retain your hard-earned place in search engines. Second, site visitors may have bookmarked pages within your old site and want to return to them. If those pages' URLs change, you need to insure visitors still receive content that is relevant to their needs, instead of a page that no longer exists.

For example, your old site may have:

  • http://oursite.com/company/history.html
  • http://oursite.com/staff/california.html

while the new site has:

  • http://oursite.com/company-history
  • http://oursite.com/staff/california

The differences are subtle, but computers are very literal things — to the browser, the difference between "history.html" and "company-history.html" might as well be the distance between Mars and Earth. You need to go through the structure of the old site and make note of every page that has equivalent information in the new site and their URLs. If your old site has a lot of pages, you can use a tool like Powermapper to help automate the process. Sometimes old and new URLs will line up pretty well, like those above. Other times an old URL may not have an equivalent in the new site. This often happens if you've closed a division of your company, discontinued a project, or reorganized a department. Regardless of the reason, you'll still need exact URLs to work with for the next step. There are three ways to handle old URLs:

  • If they have an equivalent like the examples above, you can point the old URL to the new. To diverge in to the technical for a moment, this is done with a 301 Redirect, which tells search engines and users' web browsers that a URL has permanently changed. It looks like this: Redirect 301 /company/history.html http://oursite.com/company-history
  • If the links have no equivalent, you can send site visitors to a page which says "Sorry we can't find what you you're looking for. We've redesigned and reorganized our site, and some content has changed or moved." and provide a site map and search option.
  • You can also point all non-existent URLs right to the home page.

The larger the scale of your old site, the more work will be required to re-point old URLs. If you have analytics running on your old site, you may choose to re-point only the top 10 or 20 old URLs to new ones, and set a catch-all for all the rest, pointing them either to the "Sorry, we can't find what you're looking for…" page or the home page. Creating catch-all redirects, or those that match a specific URL pattern is a technical endeavor that we won't address here, but you can easily find information on .htaccess files (for Linux server) or web.config files (for NT server) at Stack Exchange or other resources.

Never launch on a Friday

It's never a good idea to launch a website, especially one on which many people depend, on a Friday or right before holidays. If something goes wrong, you may not have the resources to fix it when most of the office staff, vendors and other third parties who might be able to help have gone home for the weekend. Mondays are best for launching a new site, as that gives you the whole week to fix any unexpected problems that may arise, and plenty of support to help you do so.


Once you've thoroughly beta tested the site, it's time to launch. Specific steps vary by project, but generally this means either moving the site (files, database, configuration) from a development environment to a public one making it visible to the world, or simply updating server settings to allow visitors to yourcompany.com to see the new site.

Post-Launch Web statistics

Reviewing your website visitor statistics can give you vital insight in to how people are using your site. You'll need at least a month or two worth of data to make any determinations. Don't get too hung up on the pure numbers — all of them are approximate to one degree or another. Trends should be your main focus. Here are a few key points to consider:

  • Where are visitors coming from? Search engines, direct traffic (i.e., someone just typed your site's.
  • URL in to the browser), ads, links from other sites, etc.
  • Where do visitors live? Are they mostly local, regional, national, international?
  • What pages are the most popular?
  • How long are visitors staying on the site?
  • What is the bounce rate, that is how many users visit only one page on the site before leaving it entirely?

Google Analytics is among the most commonly used web statistics software and you will easily find answers to these questions in the high-level data it presents. Other web statistics software like KISSMetrics or Clicky should readily provide these answers as well.

Technical documentation

You'll also need detailed notes on how various parts of the site are implemented on the CMS. This is different from the documentation provided to the business. Much of your technical documentation will simply consist of the annotated elements discussed earlier in this document, including wireframes, style guide and Photoshop documents. Think about what information would be needed if you brought new people in to maintain the site, people who were not at all familiar with it. What do they require to pick up the project? They'll need:

  • Credentials for the CMS, web server, and other services connected to the site.
  • Written or video instructions on how to perform tasks in the CMS: adding news items, blog posts, swapping out photos — everything that someone can do to the site.
  • Recommended technical maintenance — how often do the CMS and other services require updating?
  • Notes on backups — what is being backed up, how often, and where is it backed up to?

Note: writing documentation of all kinds is one of a web professional's least favorite tasks, but it's very important. Don't slack on it. Think how terrible it would be to inherit a project without any technical documentation. Then use that dread as your inspiration! You don't want to leave anybody in a lurch down the line and doing this right will save time and frustration later on.


This is often overlooked by businesses and designers alike. Schedule regular backups of the site's files and database. Daily is ideal. Your hosting company may provide an automated way to do this, but if they don't, there are plenty of effective services and tools available to facilitate this process. That way, if your files or database get hacked, erased, corrupted or otherwise damaged, you can restore them with copies from the previous day.

Depending on the size of your site, frequency of updates and some technical matters that vary with each site, you may want to schedule more frequent backups. Ideally, your site will be backed up off-site, that is, in a different place than where it is hosted. Services like Amazon S3 or Rackspace Cloud are ideal for this purpose. The idea is that if your website gets irrevocably damaged, a recent copy is stored in a different physical location, allowing restoration of the site to the last undamaged version.

Maintenance plan

Your maintenance plan, which should have been budgeted for before you started, should clarify roles and responsibilities for every aspect of the site. For example, if two articles per week are to be posted, who is responsible for this, and who is that person's backup? If your site requires photos or graphics to be created regularly, make sure this work is assigned and understood by all involved. Determine who will check links, re-size images, write blog posts, etc. Write a simple maintenance plan and share it with everyone involved in the site's care and feeding. Remember, a good website isn't a one-time event, but rather an extensible communication tool that requires regular updates to remain valuable, relevant and compelling to site visitors.

Solicit visitor feedback

After it's been online for a while, a great way to improve the impact of your site is to solicit visitor feedback. There are a variety of ways to do this, from simple online surveys to on-site focus groups. Site visitors often have trouble articulating what they like and don't like about their experience. With this in mind, it's important to craft very clear and specific questions when soliciting feedback. And remember, if you're going to take a significant amount of visitors' time, offer something in return — a product discount, prize, or simply a handwritten note thanking them.


OK, one more time for posterity: A good website isn't a one-time event, but rather an extensible communications tool. Once you've built a great website, keep the momentum going. Devote resources to regular maintenance, and check in with your site visitors regularly to identify areas for improvement.

Recommended Reading
  • "Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability" by Steve Krug
    Helps readers understand the principles of intuitive navigation and information design.
  • "Content Strategy for Mobile" by Karen McGrane
    Making the case for a mobile strategy, publishing flexibly to multiple channels, and adapting your workflow to a world of emerging devices, platforms, screen sizes, and resolutions.
  • "Design Is A Job" by Mike Monteiro
    From contracts to selling design, from working with clients to working with each other, learn why navigating the business of design is just as important as the craft of it.
  • "Grow your SEO" by Candy Phelps
    A beginner's guide to SEO.
DEFINITIONS Term Definitions Adobe Flash A proprietary system for creating rich, interactive website features such as charts, graphs, animations and streaming video. The Flash player, that is, the browser add-on that allows users to via Flash content, is free. Flash authoring software is sold by Adobe. Beta testing The process of reviewing a website to ensure everything works as intended prior to launch. Content Management System (CMS) Software that provides website authoring, collaboration and administration tools designed to allow users with little knowledge of web programming languages or markup languages to create and manage the site's content with relative ease. Offers users the ability to manage documents and output for multiple author editing and participation. Popular CMS include WordPress, ExpressionEngine, Drupal, Joomla, Perch, Statamic, Craft, and hundreds more. Grid system A grid takes the available screen area and divides it up in to equal parts, for example, 10 columns of 96 pixels = 960 pixels. This makes layout and design easier. Many grid systems are available — use a search engine to see what's current. HTML Short for 'Hypertext Markup Language.' HTML is a tag-based language which defines the elements of content on a web page. For example, surrounding content in <p>...</p> tags creates a paragraph, while <strong>...</strong> creates bold text (adapted from Wikipedia). Javascript (JS) A programming language that runs inside a user's web browser, enhancing websites with a wide range of features such as mouseovers, slide shows, moving and fading elements, and more. Commonly implemented through a library like jQuery. CSS Short for 'Cascading Style Sheets.'' CSS is a set of instructions which define the layout and appearance of HTML elements. For example, CSS may specify that all paragraphs be 12 point Verdana, dark gray. Layout Deals with the arrangement of visual elements on a page. It generally involves organizational principles of composition to achieve specific communication objectives. Lorem Ipsum ("Greeking") Placeholder text used by web and graphic designers to fill space in mockups and incomplete web pages until real content is provided. May be as old as the sixteenth century. Meta tags Information about a web page (for example, title, description, author) that helps search engines and other resources understand the contents of that page. Responsive Web Design (RWD) A set of web design techniques that insure a site adjusts its presentation appropriately for different devices. Term originally coined by Ethan Marcotte. Search Engine Optimization (SEO) The process of affecting the visibility of a website in a search engine's results. URL Stands for Uniform Resource Locator, that is, a unique address on the web that contains specific content. For example, tastyfruit.com/citrus/oranges Wireframe A visual representation of the layout elements of a web page, intended to show page structure, element placement and sizing. (vf, ra, yk, il)
Categories: Web Design

How To Prevent Common WordPress Theme Mistakes

Smashing Magazine - Mon, 03/05/2018 - 03:25
If you’ve been thinking of creating free or premium WordPress themes, well, I hope I can help you avoid some of the mistakes I’ve made over the years. Even though I always strive for good clean code, there are pursuits that still somehow lead me into making mistakes. I hope that I can help you avoid them with the help of this article. 1. Don’t Gradually Reinvent The Wheel Be careful when making things look nice — especially if you create a function that does almost exactly the same thing as another function just to wrap things nicely.
Categories: Web Design

12 Best Magazine Themes for WordPress Websites

WordPress is an excellent platform to build your online magazine site on top of. There are hundreds of high-quality magazine themes out there that come with all the features...

The post 12 Best Magazine Themes for WordPress Websites appeared first on Onextrapixel.

Categories: Web Design