The bar is set high for today’s mobile apps. First, apps must meet the standard of quality that app markets expect. Secondly, mobile app users are very demanding. Plenty of alternatives are available to download, so users will not tolerate a buggy app.
Because mobile apps have become such a crucial part of people’s lives, users won’t be shy about sharing their love or hate for an app — and that feedback gets in front of millions of users in seconds.
We take web fonts for granted these days. We didn’t always have the option of setting our text in almost any typeface. I mean, we could, but then we’d have to sigh and say, “Well, that’ll look good on about five people’s computers. Hope everyone else likes Verdana!”
Web fonts brought some much needed variety to the seen, a few abuses of typography, some extra page weight as the fonts themselves were loaded, and flashes of unstyled or invisible text. Well… omelette, eggs, breaking, you get the idea. It was bound to happen.
If users are stuck looking at a blank page for too long they might just decide to leave
It’s a bit of a usability problem, though, when text is invisible until the custom font gets loaded. If users are stuck looking at a blank page for too long (and too long might be milliseconds) they might just decide to leave. And that’s fair enough. It’s not user-friendly.
Fast forward a few years, and we’re making progress on controlling the way fonts load. Until now, we’ve done it with third-party libraries and APIs. But now, at last, this functionality is coming to CSS.
Enter the font-display property. It’s currently only in Opera, Opera for Android, and Chrome. (It was first introduced in Chrome 49 as an experimental feature.)
It comes with four options: auto, swap, fallback, and optional.
Basically, choosing font-display: auto will leave the browser to act as it does now. Text will be invisible until the custom font loads.
swap is probably what most people will use. If the font isn’t loaded, the next available font defined in the font-family property will be used. When the web font loads, it will be replaced. This is basically a flash of unstyled content, but that’s more user-friendly than invisible content, I think.
fallback splits the difference between those first two options. For a delay of 100 milliseconds, the text will be invisible. If the custom font is loaded by then, it will be used. If not, the next font in the line of succession will rule until the custom font is loaded.
optional works like fallback, except the browser may decide not to load the custom font at all, if the user’s connection is too slow
optional works like fallback, except the browser may decide not to load the custom font at all, if the user’s connection is too slow.
And there we have it. Mind you, the display-font is meant to be used in a @font-face declaration. That means it won’t work with third-party font providers like Typekit or Google Fonts for now. Once display-font becomes more widespread, however, it’s likely that they’ll implement some sort of option for this feature.
The vast majority of websites are designed in the hopes that visitors will complete an action. Buying, subscribing, commenting… from massive social media juggernauts like Facebook, to small artisan websites selling local, hand-made crafts, this is true. Marketing has always been about understanding the subtle ways which presentation, repetition, and other visual or sensory artifacts can influence the decision-making patterns of consumers. Marketing, almost since it’s inception, has relied on data – in the form of research of all kinds – to achieve its end goal. So, data-driven web design is, all-told, simply any kind of website design which utilized visitor data to modify design for optimal results.
The ability of websites to respond to data has dramatically improved in recent years. The advent of easily-parseable analytics platforms, self-modifying websites, and other fantastic tech tools have allowed website designers to modify their product to more optimally meet the goals of the owner in real-time. We’re going to talk today about using data to draw the line between visitor data and design improvements which maximize benefit both to the owner and the end user.
Because it is also true that web design should always serve the visitor, a design which is overcomplicated or tedious for users will almost always fail, in some respect, in the goal of its use.
Data-Driven Design:
Sure, marketing or user data has almost always been used to influence and guide web design to some degree, but what does data-driven design mean for us today? The answer to that question requires taking a good look at what data is. Most data is either quantitative (numerical) or qualitative (non-numerical). And the vast majority of easily-accessible data is quantitative. For example, Google Analytics informing you that 10 visitors viewed one blog page, while 1 visitor stopped by another.
Qualitative data is important. Following the numbers can help you find what visitors value and what they do. But it doesn’t tell you why they like it. And understanding that requires qualitative data. The best web design companies are pushing the field by getting qualitative data and modifying their designs based on this data. They’re using beta-testing systems and getting powerful, direct feedback.
A good data-driven design program will always use both kinds of data. Testing, analysis, and feedback systems are continuous, rather than one-off, and therefore provide deeper insights on what visitors prefer and want the websites they visit to do for them. It is this kind of deep-digging which pushes the horizon of design forward in ways which are meaningful for users.
Getting Specific, Actionable Data:
Whether the data used in data-driven design is numerical or no, it must always be empirical, and address specific questions. Whether you’re a UX designer or a data analyst, a little bit of scientific inquiry comes into play at some point, because you’re not just wanting to look at aggregate data… but to answer specific questions.
Hypothetically, this could look like a situation in which a blog or online magazine, which has hired a designer to update their website. The goal of the website is to keep visitors engaged and to provide useful information, but also to increase subscriptions. As a designer, those are several goals to meet, and ideally you should begin studying the existing website to identify key areas of improvement.
Key quantitative data metrics you might study include the bounce and exit rates, and find out which pages have the highest in each category. This provides information on a ‘what’ which you should try to address! From there, you might use UX testing to get qualitative data from visitors on their experiences from these pages to find out the why. User-reported information might reveal that page-specific CSS makes exit links larger or more obvious on these pages, therefore funneling users away. Lots of moving elements might bog down the pages, providing a negative user experience.
But in this hypothetical situation, you have used empirical information addressing specific issues to yield information which should influence design decisions. And when you start employing this one-two punch to achieve great design, you’ll realize some amazing trends.
The Big Takeaways of Data-Driven Design:
Applying data-driven design has helped push design elements which were once novel and boutique into the realm of commonality. Responsiveness, high-contrast CTAs, flat design elements were all once thoroughly tested and checked by data-driven design teams. But that’s just the beginning! Increasingly, data-driven design is finding that design decisions should be tailored to specific audiences. Right now, this is most commonly seen as different landing pages or page elements for different geolocated areas. But designers are even experimenting with segmenting design by audiences even more: by age, for example.
Testing for data and then using that data to modify design can be resource-intensive, that’s true; but even small, focused efforts can result in big improvements for clients, and the increasing ability to meet the goals of the websites we’re building.
The vast majority of websites are designed in the hopes that visitors will complete an action. Buying, subscribing, commenting… from massive social media juggernauts like Facebook, to small artisan websites selling local, hand-made crafts, this is true. Marketing has always been about understanding the subtle ways which presentation, repetition, and other visual or sensory artifacts can influence the decision-making patterns of consumers. Marketing, almost since it’s inception, has relied on data – in the form of research of all kinds – to achieve its end goal. So, data-driven web design is, all-told, simply any kind of website design which utilized visitor data to modify design for optimal results.
The ability of websites to respond to data has dramatically improved in recent years. The advent of easily-parseable analytics platforms, self-modifying websites, and other fantastic tech tools have allowed website designers to modify their product to more optimally meet the goals of the owner in real-time. We’re going to talk today about using data to draw the line between visitor data and design improvements which maximize benefit both to the owner and the end user.
Because it is also true that web design should always serve the visitor, a design which is overcomplicated or tedious for users will almost always fail, in some respect, in the goal of its use.
Data-Driven Design:
Sure, marketing or user data has almost always been used to influence and guide web design to some degree, but what does data-driven design mean for us today? The answer to that question requires taking a good look at what data is. Most data is either quantitative (numerical) or qualitative (non-numerical). And the vast majority of easily-accessible data is quantitative. For example, Google Analytics informing you that 10 visitors viewed one blog page, while 1 visitor stopped by another.
Qualitative data is important. Following the numbers can help you find what visitors value and what they do. But it doesn’t tell you why they like it. And understanding that requires qualitative data. The best web design companies are pushing the field by getting qualitative data and modifying their designs based on this data. They’re using beta-testing systems and getting powerful, direct feedback.
A good data-driven design program will always use both kinds of data. Testing, analysis, and feedback systems are continuous, rather than one-off, and therefore provide deeper insights on what visitors prefer and want the websites they visit to do for them. It is this kind of deep-digging which pushes the horizon of design forward in ways which are meaningful for users.
Getting Specific, Actionable Data:
Whether the data used in data-driven design is numerical or no, it must always be empirical, and address specific questions. Whether you’re a UX designer or a data analyst, a little bit of scientific inquiry comes into play at some point, because you’re not just wanting to look at aggregate data… but to answer specific questions.
Hypothetically, this could look like a situation in which a blog or online magazine, which has hired a designer to update their website. The goal of the website is to keep visitors engaged and to provide useful information, but also to increase subscriptions. As a designer, those are several goals to meet, and ideally you should begin studying the existing website to identify key areas of improvement.
Key quantitative data metrics you might study include the bounce and exit rates, and find out which pages have the highest in each category. This provides information on a ‘what’ which you should try to address! From there, you might use UX testing to get qualitative data from visitors on their experiences from these pages to find out the why. User-reported information might reveal that page-specific CSS makes exit links larger or more obvious on these pages, therefore funneling users away. Lots of moving elements might bog down the pages, providing a negative user experience.
But in this hypothetical situation, you have used empirical information addressing specific issues to yield information which should influence design decisions. And when you start employing this one-two punch to achieve great design, you’ll realize some amazing trends.
The Big Takeaways of Data-Driven Design:
Applying data-driven design has helped push design elements which were once novel and boutique into the realm of commonality. Responsiveness, high-contrast CTAs, flat design elements were all once thoroughly tested and checked by data-driven design teams. But that’s just the beginning! Increasingly, data-driven design is finding that design decisions should be tailored to specific audiences. Right now, this is most commonly seen as different landing pages or page elements for different geolocated areas. But designers are even experimenting with segmenting design by audiences even more: by age, for example.
Testing for data and then using that data to modify design can be resource-intensive, that’s true; but even small, focused efforts can result in big improvements for clients, and the increasing ability to meet the goals of the websites we’re building.
While the richness and interactivity of the average website has changed dramatically over the last decade, the same can be said about the expectations of those who consume it. This page has a list of reports that show how businesses were able to establish a direct correlation between the their website’s performance and conversion/revenue figures. For example, the engineering team at the Financial Times conducted a test which showed that an increase of just one second in load time caused a 4.9% drop in article views.
The underlying cause is pretty simple and it affects projects of all sizes (yep, including yours): users are becoming more demanding, less patient and not tolerant towards slow websites or applications. If your content takes too long to load, people will go somewhere else. Visiting a site that takes ages to open and navigate is a terrible user experience, especially on the dominant mobile environment where immediacy is crucial and battery life is precious.
For that reason, website performance optimisation plays an increasingly important role in the success of any online property. All major browsers ship with tools that allow developers to keep an eye on some important performance metrics as the build progresses, but these are measured from the developer’s own standpoint, which is not enough to see the full picture.
Factors like geographic location, connection type, device, browser vendor or operating system can heavily influence perceived load times, so testing all these variables is the only way to get a (mildly) accurate representation of how a website is experienced by a broader audience.
There are various tools and services to approach that problem, but this article will focus specifically on WebPageTest. We will look at it from a developer’s perspective, in particular at using its RESTful API to extract vital information you can use to optimise the performance of your site.
WebPageTest is an open source performance testing tool, maintained primarily by Google. It consists of one or multiple servers that act as web browsing robots, visiting websites and automatically collecting data about the experience in the form of a detailed performance report.
There is a public instance with a large pool of servers that is available for anyone to use for free, which is what we’ll be using in the examples throughout the article. Alternatively, the source code for the platform is available on GitHub, should you want to host it privately on your own infrastructure.
Running a test
When you open the WebPageTest website, you’ll see the interface that allows you to run a test straight away. The first thing you need is the URL of the page to be tested. On top of that, there many parameters that can be configured, with the main ones being:
Connection speed
Test location
Whether to capture a video of the test
Number of tests to run (doing a single run means that the test results are more easily influenced by network or server anomalies, so WebPageTest consider a best practice to run a test multiple times and use the average as a most representative result)
Single or repeat view (you can choose whether to load a page once or twice per test; because browser cache is cleared before each test, this effectively means deciding whether you’re only interested in the initial, uncached view, or you want a second time to leverage the browser cache)
Requesting a test on WebPageTest
For this example, we’re testing https://css-tricks.com with the default settings: Chrome on a Cable connection from Dulles, VA, performing a single run with first and repeat view, with video capturing enabled.
After requesting the test, you will enter a waiting period, as the pool of devices is shared by everyone using the public instance of WebPageTest. For this reason, tests take an unpredictable amount of time to complete, depending on the number of people using the devices and the complexity of the test.
This link contains a list of all available resources and their capacity at any given time.
Reading the results
The amount of information shown in the test reports can be a bit overwhelming, so it’s worth having a look at some of the key metrics returned and what they mean:
Load Time: The time between the initial request and the browser load event
First Byte: The time it takes for the server to respond with the first byte of the response (in other words, the time it takes for the back-end to load)
Start Render: The time until the browser starts painting content to the screen
Speed Index: A custom metric introduced by WebPageTest to rate pages based on how quickly pages are visually populated (see here for full details on the metric)
DOM Elements: Number of DOM elements in the page
Document Complete: Set of metrics relative to the time until the browser load event, with Time, Requests and Bytes In representing the load time, number of requests and number of bytes received, respectively
Fully Loaded: Similar to Document Complete, but the metrics are relative to the time at which WebPageTest determines that the page has fully finished loading content. This is relevant and different from the above, because pages may decide to load additional content after the browser load event
Test results page on WebPageTest
The waterfall view is another key piece of the report. It shows a visualisation of the network activity over time, with each horizontal bar representing an HTTP request. The colours in the bars represent the five phases of a request: DNS lookup (teal), initial connection (orange), SSL negotiation (purple), time to first byte (green), and content download (blue).
It also shows vertical lines to mark key events in the lifecycle of the page, such as the time it takes for the browser to paint the first pixel (green), the point at which the DOM tree is ready (pink), or when the document is loaded (blue). Finally, it shows redirects (highlighted in yellow) and errors (highlighted in red).
We requested a video recording as part of the rest, so WebPageTest gives us a set of frames that visually show the page being drawn on the screen over time. We can use this data to generate a filmstrip view or an actual video.
Video of CSS-Tricks being loaded on WebPageTest
WebPageTest API
With the basics of the platform covered, let’s dive into how we can interact with it programatically.
WebPageTest offers a RESTful API for public use. Because it’s a shared instance, usage is limited to 200 page loads per day — repeat views count as a separate page load, which means that a test with two runs and a repeat view would count as four page loads.
It’s also worth mentioning that test results are only kept on the servers for 30 days, so make sure you save any data you might need for posterity (including images and videos) to your own infrastructure.
Anything you can do on the WebPageTest UI can also be done programmatically, as the site itself makes use of the RESTful API. You can request tests and obtain the results, which you can then feed into a variety of outlets, like a data visualisation tool, continuous integration process, trigger Slack or email alerts, or pretty much anything.
The code examples shown throughout the article are written in ES5 JavaScript for a Node.js environment, making use of the WebPageTest API wrapper. But because the API is RESTful, it can be accessed using any language or environment capable of sending an HTTP request, so everything you’ll see here can be ported to your language of choice.
Setting up
The first step is to request an API key. After filling in your details, you should get a key straight away.
With that done, we can set up a new Node.js project and install the WebPageTest API wrapper.
npm install webpagetest --save
var WebPageTest = require('WebPageTest')
var wpt = new WebPageTest('https://www.webpagetest.org/', 'your-api-key')
The WebPageTest constructor takes two parameters:
The URL of the WebPageTest instance (unless you’re using a private instance, this will be https://www.webpagetest.org/)
The API key
Running a test programmatically
We’re going to repeat the test we did before, but this time programmatically using the API. We need the runTest function, which takes two parameters:
The URL of the site being tested
An object containing a list of options to configure the test (see here for a list of all available options)
Remember that requesting a test puts you in a waiting list, so the response you’ll get from running the code above is not the actual test result, but more of a receipt that you can use to check on the progress of the test and obtain the results when they’re ready.
We’re particularly interested in data.testId, as it contains a string that uniquely identifies our test. We can pass it to the getTestStatus method to check if the test is ready.
wpt.getTestStatus('160814_W7_960', function processTestStatus(err, result) {
console.log(err || result)
})
Eventually (depending on how busy the platform is) you’ll get a response containing:
At this point, we know that the test results are ready and we can fetch them using getTestResults.
wpt.getTestResults('160814_W7_960', function processTestResult(err, result) {
console.log(err || result)
})
This method of getting results involves some manual work on our end, as we need to keep calling getTestStatus until we get a 200 response, and only then call getTestResults. There are two alternative (and more convenient) ways of doing this:
You can pass a pingback option to runTest, containing a URL to be called by WebPageTest once the test is complete. This could be a route in your web server built specifically to handle test results. The test ID will be passed as an id query parameter, which you could use to call getTestResults.
You could incorporate all three steps (requesting, polling and retrieving) in the call to runTest by providing a pollResults option. Its value, in seconds, represents an interval used to poll the API for the status of the test. The execution will only finish once the test results are returned.
The following example (using option 2) is a combination of all the steps we’ve seen, and uses one single call to runTest to request a test, poll the API every 5 seconds until the result is ready, and finally output the results.
I’m not going to include the full response here because it’s massive (375KB of data!), but you can see it in its entirety here. Instead, we’ll see how we can drill down into it to find some of the metrics we described earlier.
The metrics shown above are just a small subset of everything WebPageTest captures, as you can see by dissecting the full result payload. But sometimes it’s important to measure other things, like metrics that are only relevant to the specific website being tested.
With WebPageTest, we can do this with custom metrics, a feature that allows us to execute arbitrary JavaScript code at the end of a test.
For example, we could be interested in tracking the performance impact caused by the number of iframes that are being loaded, or by any ads being served from a specific provider. Let’s see how we can measure that.
Each metric is defined as a block of JavaScript preceded by an identifier in square brackets, separated by a line break.
To get the number of iframes, we’re simply finding and counting all elements in the DOM. As for the ads, we’re looking at all nodes that contain ads.doubleclick.net in the href attribute. These are simplified examples for the sake of conciseness, but you can define metrics with routines as long and complex as you want.
This article describes custom metrics in depth, offering some really interesting insight on what is worth measuring.
Scripting
By default, a test consists of WebPageTest visiting a site and capturing data until the point it’s fully loaded. It then extracts any custom metrics, if defined, and the test if finished. While this works for most cases, WebPageTest offers a scripting functionality that allows you to create more complex, multi-step test routines.
For example, you can create a test that emulates a user clicking on a button, filling details in a login form or pretty much any physical interaction you could normally have with the page.
Scripts consist of a list of instructions containing custom commands (see this link for a list of available commands), encoded in an array of objects that is then converted to a string using a scriptToString method.
When running a scripted test, the normal way of passing the target URL to runTest isn’t valid. Instead, the script itself will indicate the link(s) that WebPageTest should follow, so you must include at least one navigate command followed by a URL (values are tab-separated).
By design, there can be only one command outputting test results, so multi-step tests should make use of the logData to toggle the production of results on and off based on the commands you wish to capture.
In the example below, we’ll create a test that navigates to https://css-tricks.com and fills in the search box with the term flexbox. At this point, we turn on the output, submit the form and wait for it to complete. This multi-step test will capture the experience of using the search functionality on the site.
It’s pretty common for websites to rely on third-party sources to deliver key parts of its data, such as fonts or scripts, so it’s important to account for the possibility that those services might fail at some point.
This is particularly important when the assets being loaded are render-blocking (i.e. not loaded asynchronously), as trying to load a file from an unavailable source could leave the site hanging for a while until the request times out. The video below shows the effect caused by an outage of the Twitter API on the load times of the Business Insider website.
To make our tests account for this, it’s important to get the failing mode right, as described by Patrick Meenan in this article.
Because unavailable services won’t typically fail instantly with an error message, setting up a test that tries to load something from a-host-that-doesnt-exist.com isn’t good enough, because it doesn’t accurately reflect what happens in a real scenario.
Instead, Patrick set up a special server on blackhole.webpagetest.org: as the name suggests, it routes any request made to it to absolutely nowhere. If we intercept all the requests made to the host we’re trying to test and redirect them to this black hole server, we have a very good simulation of a real failure scenario.
The example below shows how we could run a test that simulates a failure in code.jquery.com, which many sites use to load jQuery from. We could compare the results obtained with the ones from the normal test to have an idea of the impact this single point of failure would have on the various performance metrics.
var script = wpt.scriptToString([
// Redirecting 'jquery.com' to the black hole server
{setDnsName: ['jquery.com', 'blackhole.webpagetest.org']},
{navigate: 'https://css-tricks.com'}
])
wpt.runTest(script, {
location: 'Dulles:Chrome.Cable',
firstViewOnly: false,
runs: 1,
video: true
}, function (err, result) {
// Extract your metrics here
})
Wrapping up
This article isn’t an attempt of a comprehensive guide on WebPageTest, since that’s material for an entire book! Instead, we focused on what the platform is, the information it provides and, more specifically, how to interact with it programmatically.
But extracting the data is just the start — it’s what we do with it that can impact how our websites perform. I’ll follow up soon with my take on using what I’ve shown here to build a bespoke performance monitoring tool, with the ability to visualise performance metrics over time, establish performance budgets and receive alerts when they’re not met.
Universally, everything that sticks around for a while undergoes a process of specialization, and WordPress is not an exception to this rule. WP has been with us for a long time, boasts a widespread amount of installs, and it’s periodically worked on, and updated. On the front-end side of things, any developer will have not failed to notice that themes, with time, have shifted more and more out of static design forms. They have evolved into design tools in themselves, in the sense that their aim is to become “The Only Theme You Ever Need”. What they mean is that, instead of being locked up into a static design as it used to be the norm, you get a set of building blocks to design your own themes ad infinitum.
“When you do, you’ll be treated to a very different experience in the way of edition: a really fast, interactive, and well thought interface”
I find this “multi-purpose” idea brilliant, both from a design and a practical perspective. In terms of design, learning a particular tool well leads to more confidence, speed, and recycling. From a practical perspective, there’s no need to spend any more time or money hunting for themes for your next project: make up your own with the tools you know, and recycle your best blocks and components.
In the search for the theme to end all themes, I’ve run into Bateaux, by developer TwistTheme, so let’s see how well it fills this niche.
OPENING
The download is about 30 mb, and the first pleasant surprise is the inclusion of a child theme to work on without fear of losing your tweaks with the next update. After installing the theme and the core plugins, the next move is either to configure everything from zero, or to perform an import of the included sample data and take it from there. The sample designs are pretty cool and will get you on your way very quickly if you don’t have the time to re-invent the wheel. Control over typography is handled through Google Fonts, Typekit and Custom Fonts. The theme is multi-language through WPML integration, and not only does it support WooCommerce, it comes preloaded with modules for it, and offers tailored options when you’re editing a product page. This is great.
The theme’s looks and behavior are controlled via the Customizer, and it’s refreshing to have buttons that show what everything looks like in tablets and mobiles, with instant visualization. After all the setting-up is done, your next stop will be to become familiar with the strongest feature of this theme, which is the signature “Blueprint” page-builder.
The Blueprint page-builder is an original invention of the authors, and you can tell they have poured a lot of effort into it. Essentially it’s a separate app, available whenever you edit a post or a page. You can opt to edit in the classic way, or to fire Blueprint. When you do, you’ll be treated to a very different experience in the way of edition: a really fast, interactive, and well thought interface, which you can use to build your creations: structure sections within sections, edit properties with context-aware option panels (it includes a full-screen button to maximize space, and a Preview button -which works in real time- as well) and a lot more.
Through Blueprint, you will play around with lots of universal building blocks such as blog entries, contact forms, galleries, featured posts, product categories for your shop, sliders, and also elements unique to Bateaux, such as testimonials, team, modal (pop-ups), and other interactive elements. This, in sum, is where the action happens, and the core area from where you can unleash your creative potential to invent something new, or simply use any of the included templates, which look already great in terms of grid design and visual space. It will take some time to get used to, but probably visual design interfaces are where the future of WordPress is heading towards. Bateaux’s Blueprint editor does a really fine job at offering all of that today. To sum up Bateaux:
THE GOOD:
Great design, elegant and aesthetic.
Truly responsive and retina-ready.
Nice included toys like Slider Revolution.
Lots of cool templates and designs out of the box.
Not only WooCommerce-friendly, but including pre-made designs to deploy right away with your shop.
Multi-lingual ready through WPML compatibility. – A bazillion of options for customization.
Fast: GTMetrix reports a PageSpeed score of 97%
A truly useful, original and quick page-builder that may arguably hold the key to the “last theme you will ever need” WP holy grail: why buy any other theme, if you can build anything you can think of using this one? Moreover, the more you use it the more you’ll know how to get what you want.
Clean and light page-builder. Since the author designed Blueprint very light and clean, you will find it very fast compare to other page-builder in the market. Everything interacts real time with no waiting time and need to click “save” button.
Zealous, responsive customer service.
THE NOT-SO-GOOD:
A lot but worth to learn. The downside of not having to mess with the code is of course the amount of options available, to tweak the theme so it will do what you want. You’ll need to dedicate a certain amount of time to understand where everything is, what it does, and how it does it.
The documentation is okay, but needs expanding with more detail on the concepts, and examples. But they are reportedly working on it.
VERDICT
Bateaux is built aesthetically around typography and intelligent grids, with great attention to detail, so it looks gorgeous. It comes with a lot goodies out of the box, and many fantastic designs to kick off. It’s clearly built from the ground up upon the new WP ethos of being not a theme, but a platform to create themes. As such, everything can be adjusted through options, which is great if you look for quick WP development cycles and minimal fiddling with coding. The flip side of so much control is obviously the massive amount of options needed to set everything to your liking. And since each designer crafts their theme according to their own idiosyncrasy and ability, stuff is located in different places, organized under its own internal logic. In that sense, Bateaux needs, in my opinion, to reorganize its options a little bit, and to expand on the documentation. The authors have told me they are indeed working on this.
In terms of support from the developers, I must say it has been excellent. I have contacted them with a couple of questions and got a succinct reply in less than an hour, which is great in my book (consider other themes’s authors who’ll take a week to reply, if at all). By browsing Bateaux’s support forum you can quickly tell issues are dealt with quickly and efficiently, and that the authors are really behind their theme. Hopefully they will continue to develop it and expand it even further. Highly recommended.
Websites have become table stakes for companies. Even the newest start-ups—who don’t yet have products—have a website. The reason being, a website is the front door to a brand. It is the first opportunity, in an available and relatively inexpensive way, for customers, employees, and the world to understand who they are, why they do what they do and what they’re all about.
So why do so many websites end up resembling an interactive brochure?
I go back to the fact that today, websites are ‘available and relatively inexpensive.’
Website builders have promised, “to help anyone build a beautiful home online.” And they often keep this promise. But what they don’t say is that the home will be more of a tract home. To make sites available to everyone (no coding or design knowledge required), your site will be based on a template. Those templates are generic enough that the same template is used by a non-profit, a fashion line, and a punk rock band. The change comes visually—different colors, photos and typefaces. However, moving off of the homepage and hero image, the experience from site to site feels similar.
A website is an opportunity to communicate a brand identify and purpose, therefore it should showcase what makes you you. Right now, too many businesses are missing this opportunity.
Expressing brand values
Your values are core to any brand. They are what helps you translate what a brand is promising conceptually, to how a brand is keeping that promise experientially.
Patagonia‘s core values are: Quality, Integrity, Environmentalism, and Not bound by Convention. Their website is beautiful, with high quality photos of people wearing the products in adventurous places. However, if I knew nothing else about the brand than the website, they wouldn’t feel different from any other adventure brand trying to sell me a fleece jacket.
Their values are what makes Patagonia unique. Thinking about “Not bound by convention”, what can that look like as navigation? Right now the shop is organized by man, woman, child, etc; pretty conventional. Is there a different way to think about this where maybe everything is organized by item type without gender or age classification? Maybe that specific classification is actually about fit not gender/age, and so that selection can be done at point-of-purchase sizing.
Changing something to better express the brand values can change the way we understand the brand after an interaction.
Values dictate interaction
Modern day consumers have much higher expectations of customer service experience. Either it’s not enough—all that is provided is a 1.800 number—or it’s too much—there’s a help chat box that keeps popping up every time you are on a new page. For some brands, where service is truly at its core, figuring out the right approach is incredibly important.
One of Southwest‘s values is “a servant heart”. Why then is the “Contact Us” only available on the footer for the general pages? When I need help, it’s usually because I have a question about my flight reservation. A better solution would be a slider on the side at all times that reads “Can I help you?” So that when I look at my flight reservation I can easily ask questions via chat.
While many customers may decide never to contact Southwest via this channel, the point is that if they’d made it available, anytime, anywhere, it would demonstrate they encourage communication and appear to be proactive—really conveying the meaning behind that core value.
Engaging with physical space
For brands with digital and physical touchpoints, an important consideration is how they compliment each another. There are different expectations on each medium, and while they don’t always need to work together in unison, they should always be in harmony.
The Los Angeles County Museum of Art (LACMA) has a mission statement to: “serve the public through the collection, conservation, exhibition and interpretation of significant works of art…” Their website is a solid information hub with pretty pictures and everything you’d need in order to visit the museum—however it’s not responsive. By building a mobile site that integrates ways for visitors to enhance their museum experience LACMA can further strengthen their mission to educate and engage the city of LA.
For example, could the audio tour be loaded on the website allowing a visitor to use their own cellphone and earbuds? Could QRS codes be added in the center of a room, and when a visitor scans them, it provides them with relevant information about the artwork in that room?
While it doesn’t always make sense for web and world to interact in this manner, LACMA’s mission suggests it’s about driving visitors to come to the museum. Adding in museum interactive aspects to the website would allow visitors to interact without having to download an app.
Many companies using WYSIWYGs cannot invest in custom web development, but these questions can help you to get to the next level of experience. Content development, choice in template, it’s important to consider what these are saying about your brand. While having a website may be table stakes, going beyond a pretty digital brochure can make it something truly meaningful.
A few months ago, Jason Grigsby’s post about autocompletion in forms made the rounds. I loved the idea of allowing users to fill in their credit card details by taking a picture of their card. What I didn’t love was learning all of the possible values for autofill by heart. I’m getting lazy in my old age.
Lately, I’ve gotten spoiled from using an editor that does intelligent autocompletion for me, something that in the past only massive complex IDEs offered. Opening my editor of choice, I created an input element and added an autocomplete attribute, only to find that the code completion offered me the state of on or off. Disappointing.
The development of websites can be a slow and tedious process at times. Especially when you’ve got yourself a client that doesn’t have a clear idea of the project. Now, it could be tempting to simply get the website online as fast as possible. However, that’s not really advantageous to you.
If your think that you can get the website up fast, and just remove the final errors while it is already live, this approach could definitely get you into some trouble.
Even a difficult client is entitled to quality and should be a part of the process at any given moment. Both parties should know what will be delivered, and when this will happen.
You as a web developer should know that committing hara-kiri could easily hurt your reputation. Releasing incomplete websites and working on them afterward will certainly be talked about. This can’t be beneficial to you and your reputation.
The Checklist for the Website Launch
To keep this and other problems off you, I have compiled a checklist that is supposed to help you only release “finished” websites from now on.
1 – Check the Agreed on Extent of Work
(Hopefully) Your client and you have agreed to a precisely defined extent of work at the beginning of the project. During the work on the website, this extent could have increased, but if that’s the case, this should be written down.
So the website owner has made an agreement with you about which elements the website should contain. How many pages, which contents, who creates the contents, whether the website should have a slider, which particular functions are desired, and so on.
Go through the list and check if all the agreed on features and elements are there and working. If the list is not completed, go ahead and do so.
2 – Check Every Single Page
Now, every single page should be tested in detail. Look at every element and check if it looks the way it’s supposed to. Everything working? Check it. Above all, check the following:
The Logo
The Navigation
The Images and Graphics
The Texts – Also Pay Attention to Proper Display
The Call-to-Action Elements
The Forms (Contact Form, Newsletter)
The Links
The Google-Maps
The Contact Information
The Imprint
The Social Media Buttons
The Widgets
The Logins
All of these things have to function and be displayed well.
3 – Test the Content
Especially the content, the texts are relevant. Not only do they have to look good, but they also need to be written as well and faultless as possible. Thus, take a close look at every single text area. Conduct detailed controls on whether the display is optimal or not. If there’s room for improvement of the text areas, go for it.
When the texts’ design is optimal, check the content for spelling mistakes. Don’t let texts with errors go online. Your reputation will suffer from that.
4 – Check the Photos
For many companies and branches, an optimal representation on photos is extremly important. That’s why you need to check every single photo to see if its quality is sufficient. If some areas are not equipped with meaningful photos yet, either place great stock photos or ask the client to find someone to take professional images.
If photos of the company headquarters and workers, professional photos are inevitable. You should tell your client that he should spend money on that.
Important: Is the favicon working? A favicon is a crucial part of a website’s identity.
5 – Checking the Privacy Policy and the Imprint
Is there a privacy policy and is it written correctly? Are the social networks listed up? Check and correct these aspects, if necessary. Also look at the imprint and see if you paid attention to all required information.
Special rules apply for ltd.’s and corporations. If necessary, make sure to comply.
6 – Check for 404 Error Messages
When you reach this point, you’ll already have tested every link within the website. Have you also considered that 404 errors could come up due to wrong user input? Each website should have a custom 404 error page so that users can understand the error message.
If you didn’t already create an own 404 page, now would be the time to do so.
7 – Check the SEO Status of Your Website
It doesn’t matter how good your website is if nobody finds it. Thus, an SEO test is a great thing. Test if there’s an SEO plugin installed, if the single pages have correct titles, if the titles have the proper length to be displayed in the search results (65 characters at most), as well as if there’s a custom meta description for each page.
Furthermore, you should make sure that the relevant open graph tags for social media are given out correctly.
8 – Conduct a Test Run
The goal of this step is to check on all the functions that the website provides for its visitors. There’s not much to test if it’s a simple business online presence. However, when you developed an online store, you should control all of its features. Make a test purchase.
If it’s connected to a customer relationship management (CRM), also examine its features, and look if all the necessary data is imported.
9 – Test the Mobile Friendliness
Today, every website should be responsive, meaning that it adjusts to any screen resolution. Conduct in-depth tests on different, real devices to see if all elements are displayed correctly, and if further elements could or should be hidden.
Each of the website’s pages should look good on mobile devices, both proportions and text size should fit.
10 – Test the Browser Compatibility
The stipulated scope of work should include which browsers you had to optimize the website for. My advice: Ask your client if the site is also supposed to work on Internet Explorers and if so, on which versions.
Now, examine the site in all agreed upon browsers on correct design and funcitonality. If something is not optimal, fix it.
11 – Test Your Code-Quality
The quality of your HTML code is important for the website’s sturdiness. Thus, the HTML code should always be valid and free of errors when giving out a website. On top of that, sites you created are your flagship on the internet.
Don’t hand out flawed code that could be destroyed by a plugin. There are lots of validators on the web, the most popular one being the validator of the W3C.
12 – Test a Potential SSL Certificate
Does the website you created use an SSL certificate? If so, test all of the site’s pages and make sure that it will always be displayed in green, meaning that it can load all resources via HTTPS. If you happen to find errors, work on them.
Loading speed is an important factor for the user experience on any website. The faster a site, the lower the amount of bounces will be. Users are quick to decide whether they want to stay or not. Additionally, speed is one of Google’s ranking factors.
A lot of people find three seconds of loading time to be too long, so make sure that your loading time is at least near to one and a half seconds. This can be achieved without any extensive changes.
Now, take care of your website’s safety. If you didn’t take any measures yet, it is time to do that. A minimum amount of security can be achieved by using the optimal .htaccess file. Check the server safety and implement the proper HTTP header.
15 – Renew All Access Information
Before handing the website to the client, I recommend renewing all passwords and choosing reliable, safe ones. If there are simple user names like “Admin” among the accesses, choose better variants instead.
Also, make sure that users are not able to change their passwords to unsafe variants. This can be accomplished using this code that belongs into the functions.php of the WordPress theme if you created a WordPress website.
This test can be quite lengthy, but it helps you get your reputation to a high level. You will only deliver quality from that point on. This will be beneficial to you, your boss, and above all, your customers.
However, before making the website go live, ensure that the client, their admin, and maybe your boss, gave you the permission to do so. These people definitely have to look at your website, and maybe even test it in order to then give you their authorization in a written form. This way, you’re always on the safe side.
Create a bouncy ball effect in Adobe Muse with the Muse Motion 2 Widget Powered by Greensock’s Animation Platform (GSAP). No Coding Skills Required.
The Greensock Animation Platform (GSAP) is one of the most sophisticated animation platforms available for the web. With the Greensock Animation Platform you can create animation sequences and add animations to individual elements on your website. I was very excited when I first created the Muse Motion 2 widget for Adobe Muse. This gave you access to the Greensock Animation Platform without having to know any code. Developers spend hours fine tuning their code to get great animations. With the Muse Motion 2 widget the Greensock animations can be achieved with just changing a few settings in the widget.
In the video above I go over just how easy it is to create a bouncy ball effect in Adobe Muse using the Muse Motion 2 widget. Simply add a few circles, add the widget, set the settings in the widget, and apply the widget to the element. It took me less than 4 minutes to achieve this effect in Adobe Muse with the Muse Motion 2 widget.
This is the first video out of a series of videos I will be creating on how to create simple yet sophisticated animations with the Muse Motion 2 widget. I also show the Muse Motion 2 widget combined with the Muse Morph widget to transform SVG elements as they bounce. Hopefully this will inspire you for your own website :).
