The Changing Face of Web Design in 2018


Inspired Magazine
Inspired Magazine - creativity & inspiration daily
One of the interesting recent developments in web design trends is actually the trend away from trends… or in other word what is happening is a kind of regression to simpler ways, at least from those in the know.
On the other side of the coin, there’s a big shift happening in certain types of corporate sites, especially some British and American media sites, where there’s a tendency to overload pages with so much extraneous content that it can severely impact on the ability of the user to see the content they actually arrived to see.
If the first two paragraphs sound hopeless tangled, well that’s a very succinct allegory for the state of web integrationin 2018… tangled. It’s a problem we need to sort out, because it won’t be good for anyone if web standards continue to slip.
We’ll return to this topic of overloading later on in the article, because it’s quite a big topic. What I’d just like to briefly do before we get into that is to focus attention on some of the problems we’ll see being solved before that more serious problem is dealt with, and also some of the good things we’ll be seeing happening on the web design front in 2018.

Carousels are finished
There’s a place for carousels, but the abuse of them is going to end, simply because it’s been so overdone that people are tired of them.
Unfortunately on some sites they’re being replaced by something even more obnoxious, which is an autoplay video banner, but this can be expected to die out naturally as developers finally figure out that too many users are on mobile connections and slow broadband for this to be a practical idea.
Carousel abuse, by the way, is simply a situation where they’re used for no other reason than to use them, serving no real purpose to better inform or entertain the viewer.

Death of the 1-3-1-6 layout
This layout pattern was at some point decided as what should be the future of web design, because at the time it was first used, it looked kind of cool. As with many overused fashions, however, people have started to find it irritating.
The layout also is flawed from the point of view that it’s not well suited to good responsive design (even if it can be made to work in responsive design), and encourages overloading with unnecessary elements.
Again, it is a problem of including elements just so they’ll fit the layout and not because they add value to the user experience.
Increase in true responsive design
Designers are better informed now about the need for responsive design, and they’re getting a lot better at implementing it. We should expect to see a lot more sites getting responsive design right, and that can only be a net gain for the users.
As a designer what you’ll want to be conscious of is that the focus on responsive design (which is a good thing) doesn’t result in a lacklustre desktop browser experience (which would be a bad thing). We need to think about how we’re using space to make sure it is efficient and always delivering a quality user experience.

gif image courtesy of Gal Shir
Rise of the narrative theme
More commercial marketing agencies are going to realize the value of building proper relationships with users, and so we should see an increase in narrative themes, ones that draw us in with a story and informative text, instead of just presenting a wall of products for us to choose and buy.
That doesn’t mean we should go crazy with text and video, it just means we should dial down the commercial focus, instead focusing on building trust, and then convert that trust into sales.

illustration courtesy of Folio Illustration Agency
Huge problems ahead with Internet nanny state
Browsers and ISPs continue to take a hardline stance in terms of trying to protect users from their own lack of savvy, and this in turn is punishing honest developers and small business sites who can’t don’t need security certificates and can’t afford the extra cost.
What we really need is for the Internet users to become more savvy, implementing their own safeguards, instead of technology providers stepping in to do it for them.

illustration courtesy of Ben Stafford
The problem this nannying creates is that it assumes every site to be malicious until proven otherwise, ignores the fact that malicious sites routinely do things by the book to masquerade as non-malicious sites, and that truly malicious sites are a minority.
There’s also the fact that users should take responsibility for their own security, plus the equally important fact that the majority should not be punished (or restricted) because of the actions of a malignant minority.
Geolocation triggered CDN will fall out of fashion
At first it’s going to rise, then people are finally going to figure out it doesn’t work the way it is supposed to, and then (if there’s any sense left in the world) people will stop using this extremely bad idea.
What is meant to happen is the site looks at the IP address and then attempts to fetch CDN resources from the CDN server closest to the client. It would be fine except some sites try to get too fancy. They also look at the client locale and try to serve location-specific content to the client.
This inevitably leads to DNS resolution conflicts, causing even major sites such as Google and Facebook to malfunction on some client machines. It has become an issue because designers have forgotten that people travel.
Travelers don’t always reset the locale on their devices when they travel, and there can be many reasons for this. The conflict between the device locale and the IP location (unless a VPN is used) seems to cause routing problems with many sites.

image courtesy of Alexander Zinchenko
The scourge of overloaded pages
An overloaded page is one that contains a ridiculous amount of external resources, especially JavaScript, where the external resources contribute nothing positive to the user experience. These resources are included solely for the benefit of the site owner, either for making money, collecting information, or just because the designer is a plug-in junky.
Overloaded pages can be annoying for anyone, but they’re especially annoying for mobile users, users running older hardware, and users with slow connections.
It’s the kind of thing that in the past we’d expect to see on trash sites, but lately it has become a problem on many different kind of sites, including mainstream media sites.
Let’s check out an example:

What we’re looking at here is not meant to single out this particular site. It is typical of just about any UK mainstream media site these days, and some American sites are just as overloaded, if not even more so. This doesn’t look overloaded at first glance, but take a closer look.
With JavaScript enabled, a normal Internet connection, and anything less than the latest hardware, the page loading time will be spectacularly unimpressive. At least part of the reason is that the page tries to load scripts from all these domains:

Remember, if even one of these scripts fails to load, it can introduce delays and malfunctions for the rest of the page load.
Most of the news sites are adding these unprofessional click-bait ads at the bottom of their articles. These have no business on a business site. It’s amazing that they’ve been so universally adopted, and what should be a major concern is that these ads can sometimes be offensive or just annoyingly insensitive, which can lead to a backlash against your site.

Plus of course loading all these resources (including all the scripts, images, videos, and other things), puts a strain on the client machine. CPU and memory are consumed with each item loaded, and in a multi-tab browsing environment, when most browsers are still plagued with bugs, it all ads up to a potentially frustrating time for users.
You know who the users are going to blame when their browser (and maybe entire OS session) crashes? They’re going to blame you. When they do, it’s unlikely you’ll ever get that user back, or they’ll come back grudgingly, expecting problems.
It’s understandable some sites need to raise money through advertising, but there’s no way to justify connecting to 39 different domains in order to do so. It’s just going too far, when it’s not necessary. You could serve less ads, and serve them all from one place, and the results would be better.
Another advantage of avoiding overloading is fewer privacy invasions, raising the trust level of your site. Users don’t hate ads, they hate ads that get in the way of what they’re doing and which invade their privacy, even to the point of spying on them and following them around.
Let’s stop doing that, and make money honestly with clean sites the way nature intended. It can only result in more profits for your company and a better user experience for those visiting your site.
header image courtesy of Ksenia Shokorova
This post The Changing Face of Web Design in 2018 was written by Inspired Mag Team and first appearedon Inspired Magazine.
Source: inspiredm.com


Accessible Web Apps with React, TypeScript, and AllyJS

Accessibility is an aspect of web integrationthat is often overlooked. I would argue that it is as vital as overall performance and code reusability. We justify our endless pursuit of better performance and responsive design by citing the users, but ultimately these pursuits are done with the user's device in mind, not the user themselves and their potential disabilities or restrictions.
A responsive app should be one that delivers its content based on the needs of the user, not only their device.
Luckily, there are tools to help alleviate the learning curve of accessibility-minded development. For example, GitHub recently released their accessibility error scanner, AccessibilityJS and Deque has aXe. This article will focus on a different one: Ally.js, a library simplifying certain accessibility features, functions, and behaviors.

One of the most common pain points regarding accessibility is dialog windows.
There're a lot of considerations to take in terms of communicating to the user about the dialog itself, ensuring ease of access to its content, and returning to the dialog's trigger upon close.
A demo on the Ally.js website addresses this challenge which helped me port its logic to my current project which uses React and TypeScript. This post will walk through building an accessible dialog component.
Demo of accessible dialog window using Ally.js within React and TypeScript
View the live demo
Project Setup with create-react-app
Before getting into the use of Ally.js, let's take a look at the initial setup of the project. The project can be cloned from GitHub or you can follow along manually. The project was initiated using create-react-app in the terminal with the following options:
create-react-app my-app --scripts-version=react-scripts-ts
This created a project using React and ReactDOM version 15.6.1 along with their corresponding @types.
With the project created, let's go ahead and take a look at the package file and project scaffolding I am using for this demo.
Project architecture and package.json file
As you can see in the image above, there are several additional packages installed but for this post we will ignore those related to testing and focus on the primary two, ally.js and babel-polyfill.
Let's install both of these packages via our terminal.
yarn add ally.js --dev && yarn add babel-polyfill --dev
For now, let's leave `/src/index.tsx` alone and hop straight into our App container.
App Container
The App container will handle our state that we use to toggle the dialog window. Now, this could also be handled by Redux but that will be excluded in lieu of brevity.
Let's first define the state and toggle method.
interface AppState {
showDialog: boolean;
}

class App extends React.Component<{}, AppState> {
state: AppState;

constructor(props: {}) {
super(props);

this.state = {
showDialog: false
};
}

toggleDialog() {
this.setState({ showDialog: !this.state.showDialog });
}
}
The above gets us started with our state and the method we will use to toggle the dialog. Next would be to create an outline for our render method.
class App extends React.Component<{}, AppState> {
...

render() {
return (
<div className="site-container">
<header>
<h1>Ally.js with React &amp; Typescript</h1>
</header>
<main className="content-container">
<div className="field-container">
<label htmlFor="name-field">Name:</label>
<input type="text" id="name-field" placeholder="Enter your name" />
</div>
<div className="field-container">
<label htmlFor="food-field">Favourite Food:</label>
<input type="text" id="food-field" placeholder="Enter your favourite food" />
</div>
<div className="field-container">
<button
className='btn primary'
tabIndex={0}
title='Open Dialog'
onClick={() => this.toggleDialog()}
>
Open Dialog
</button>
</div>
</main>
</div>
);
}
}
Don't worry much about the styles and class names at this point. These elements can be styled as you see fit. However, feel free to clone the GitHub repo for the full styles.
At this point we should have a basic form on our page with a button that when clicked toggles our showDialog state value. This can be confirmed by using React's Developer Tools.
So let's now have the dialog window toggle as well with the button. For this let's create a new Dialog component.
Dialog Component
Let's look at the structure of our Dialog component which will act as a wrapper of whatever content (children) we pass into it.
interface Props {
children: object;
title: string;
description: string;
close(): void;
}

class Dialog extends React.Component<Props> {
dialog: HTMLElement | null;

render() {
return (
<div
role="dialog"
tabIndex={0}
className="popup-outer-container"
aria-hidden={false}
aria-labelledby="dialog-title"
aria-describedby="dialog-description"
ref={(popup) => {
this.dialog = popup;
}
}
>
<h5
id="dialog-title"
className="is-visually-hidden"
>
{this.props.title}
</h5>
<p
id="dialog-description"
className="is-visually-hidden"
>
{this.props.description}
</p>
<div className="popup-inner-container">
<button
className="close-icon"
title="Close Dialog"
onClick={() => {
this.props.close();
}}
>
×
</button>
{this.props.children}
</div>
</div>
);
}
}
We begin this component by creating the Props interface. This will allow us to pass in the dialog's title and description, two important pieces for accessibility. We will also pass in a close method, which will refer back to the toggleDialog method from the App container. Lastly, we create the functional ref to the newly created dialog window to be used later.
The following styles can be applied to create the dialog window appearance.
.popup-outer-container {
align-items: center;
background: rgba(0, 0, 0, 0.2);
display: flex;
height: 100vh;
justify-content: center;
padding: 10px;
position: absolute;
width: 100%;
z-index: 10;
}

.popup-inner-container {
background: #fff;
border-radius: 4px;
box-shadow: 0px 0px 10px 3px rgba(119, 119, 119, 0.35);
max-width: 750px;
padding: 10px;
position: relative;
width: 100%;
}

.popup-inner-container:focus-within {
outline: -webkit-focus-ring-color auto 2px;
}

.close-icon {
background: transparent;
color: #6e6e6e;
cursor: pointer;
font: 2rem/1 sans-serif;
position: absolute;
right: 20px;
top: 1rem;
}
Now, let's tie this together with the App container and then get into Ally.js to make this dialog window more accessible.
App Container
Back in the App container, let's add a check inside of the render method so any time the showDialog state updates, the Dialog component is toggled.
class App extends React.Component<{}, AppState> {
...

checkForDialog() {
if (this.state.showDialog) {
return this.getDialog();
} else {
return false;
}
}

getDialog() {
return (
<Dialog
title="Favourite Holiday Dialog"
description="Add your favourite holiday to the list"
close={() => { this.toggleDialog(); }}
>
<form className="dialog-content">
<header>
<h1 id="dialog-title">Holiday Entry</h1>
<p id="dialog-description">Please enter your favourite holiday.</p>
</header>
<section>
<div className="field-container">
<label htmlFor="within-dialog">Favourite Holiday</label>
<input id="within-dialog" />
</div>
</section>
<footer>
<div className="btns-container">
<Button
type="primary"
clickHandler={() => { this.toggleDialog(); }}
msg="Save"
/>
</div>
</footer>
</form>
</Dialog>
);
}

render() {
return (
<div className="site-container">
{this.checkForDialog()}
...
);
}
}
What we've done here is add the methods checkForDialog and getDialog.
Inside of the render method, which runs any time the state updates, there is a call to run checkForDialog. So upon clicking the button, the showDialog state will update, causing a re-render, calling checkForDialog again. Only now, showDialog is true, triggering getDialog. This method returns the Dialog component we just built to be rendered onto the screen.
The above sample includes a Button component that has not been shown.
Now, we should have the ability to open and close our dialog. So let's take a look at what problems exist in terms of accessibility and how we can address them using Ally.js.

Using only your keyboard, open the dialog window and try to enter text into the form. You'll notice that you must tab through the entire document to reach the elements within the dialog. This is a less-than-ideal experience. When the dialog opens, our focus should be the dialog  -  not the content behind it. So let's look at our first use of Ally.js to begin remedying this issue.
Ally.js
Ally.js is a library providing various modules to help simplify common accessibility challenges. We will be using four of these modules for the Dialog component.
The .popup-outer-container acts as a mask that lays over the page blocking interaction from the mouse. However, elements behind this mask are still accessible via keyboard, which should be disallowed. To do this the first Ally module we'll incorporate is maintain/disabled. This is used to disable any set of elements from being focussed via keyboard, essentially making them inert.
Unfortunately, implementing Ally.js into a project with TypeScript isn't as straightforward as other libraries. This is due to Ally.js not providing a dedicated set of TypeScript definitions. But no worries, as we can declare our own modules via TypeScript's types files.
In the original screenshot showing the scaffolding of the project, we see a directory called types. Let's create that and inside create a file called `global.d.ts`.
Inside of this file let's declare our first Ally.js module from the esm/ directory which provides ES6 modules but with the contents of each compiled to ES5. These are recommended when using build tools.
declare module 'ally.js/esm/maintain/disabled';
With this module now declared in our global types file, let's head back into the Dialog component to begin implementing the functionality.
Dialog Component
We will be adding all the accessibility functionality for the Dialog to its component to keep it self-contained. Let's first import our newly declared module at the top of the file.
import Disabled from 'ally.js/esm/maintain/disabled';
The goal of using this module will be once the Dialog component mounts, everything on the page will be disabled while filtering out the dialog itself.
So let's use the componentDidMount lifecycle hook for attaching any Ally.js functionality.
interface Handle {
disengage(): void;
}

class Dialog extends React.Component<Props, {}> {
dialog: HTMLElement | null;
disabledHandle: Handle;

componentDidMount() {
this.disabledHandle = Disabled({
filter: this.dialog,
});
}

componentWillUnmount() {
this.disabledHandle.disengage();
}
...
}
When the component mounts, we store the Disabled functionality to the newly created component property disableHandle. Because there are no defined types yet for Ally.js we can create a generic Handle interface containing the disengage function property. We will be using this Handle again for other Ally modules, hence keeping it generic.
By using the filter property of the Disabled import, we're able to tell Ally.js to disable everything in the document except for our dialog reference.
Lastly, whenever the component unmounts we want to remove this behaviour. So inside of the componentWillUnmount hook, we disengage() the disableHandle.

We will now follow this same process for the final steps of improving the Dialog component. We will use the additional Ally modules:

maintain/tab-focus
query/first-tabbable
when/key

Let's update the `global.d.ts` file so it declares these additional modules.
declare module 'ally.js/esm/maintain/disabled';
declare module 'ally.js/esm/maintain/tab-focus';
declare module 'ally.js/esm/query/first-tabbable';
declare module 'ally.js/esm/when/key';
As well as import them all into the Dialog component.
import Disabled from 'ally.js/esm/maintain/disabled';
import TabFocus from 'ally.js/esm/maintain/tab-focus';
import FirstTab from 'ally.js/esm/query/first-tabbable';
import Key from 'ally.js/esm/when/key';
Tab Focus
After disabling the document with the exception of our dialog, we now need to restrict tabbing access further. Currently, upon tabbing to the last element in the dialog, pressing tab again will begin moving focus to the browser's UI (such as the address bar). Instead, we want to leverage tab-focus to ensure the tab key will reset to the beginning of the dialog, not jump to the window.
class Dialog extends React.Component<Props> {
dialog: HTMLElement | null;
disabledHandle: Handle;
focusHandle: Handle;

componentDidMount() {
this.disabledHandle = Disabled({
filter: this.dialog,
});

this.focusHandle = TabFocus({
context: this.dialog,
});
}

componentWillUnmount() {
this.disabledHandle.disengage();
this.focusHandle.disengage();
}
...
}
We follow the same process here as we did for the disabled module. Let's create a focusHandle property which will assume the value of the TabFocus module import. We define the context to be the active dialog reference on mount and then disengage() this behaviour, again, when the component unmounts.
At this point, with a dialog window open, hitting tab should cycle through the elements within the dialog itself.
Now, wouldn't it be nice if the first element of our dialog was already focused upon opening?
First Tab Focus
Leveraging the first-tabbable module, we are able to set focus to the first element of the dialog window whenever it mounts.
class Dialog extends React.Component<Props> {
dialog: HTMLElement | null;
disabledHandle: Handle;
focusHandle: Handle;

componentDidMount() {
this.disabledHandle = Disabled({
filter: this.dialog,
});

this.focusHandle = TabFocus({
context: this.dialog,
});

let element = FirstTab({
context: this.dialog,
defaultToContext: true,
});
element.focus();
}
...
}
Within the componentDidMount hook, we create the element variable and assign it to our FirstTab import. This will return the first tabbable element within the context that we provide. Once that element is returned, calling element.focus() will apply focus automatically.
Now, that we have the behavior within the dialog working pretty well, we want to improve keyboard accessibility. As a strict laptop user myself (no external mouse, monitor, or any peripherals) I tend to instinctively press esc whenever I want to close any dialog or popup. Normally, I would write my own event listener to handle this behavior but Ally.js provides the when/key module to simplify this process as well.
class Dialog extends React.Component<Props> {
dialog: HTMLElement | null;
disabledHandle: Handle;
focusHandle: Handle;
keyHandle: Handle;

componentDidMount() {
this.disabledHandle = Disabled({
filter: this.dialog,
});

this.focusHandle = TabFocus({
context: this.dialog,
});

let element = FirstTab({
context: this.dialog,
defaultToContext: true,
});
element.focus();

this.keyHandle = Key({
escape: () => { this.props.close(); },
});
}

componentWillUnmount() {
this.disabledHandle.disengage();
this.focusHandle.disengage();
this.keyHandle.disengage();
}
...
}
Again, we provide a Handle property to our class which will allow us to easily bind the esc functionality on mount and then disengage() it on unmount. And like that, we're now able to easily close our dialog via the keyboard without necessarily having to tab to a specific close button.
Lastly (whew!), upon closing the dialog window, the user's focus should return to the element that triggered it. In this case, the Show Dialog button in the App container. This isn't built into Ally.js but a recommended best practice that, as you'll see, can be added in with little hassle.
class Dialog extends React.Component<Props> {
dialog: HTMLElement | null;
disabledHandle: Handle;
focusHandle: Handle;
keyHandle: Handle;
focusedElementBeforeDialogOpened: HTMLInputElement | HTMLButtonElement;

componentDidMount() {
if (document.activeElement instanceof HTMLInputElement ||
document.activeElement instanceof HTMLButtonElement) {
this.focusedElementBeforeDialogOpened = document.activeElement;
}

this.disabledHandle = Disabled({
filter: this.dialog,
});

this.focusHandle = TabFocus({
context: this.dialog,
});

let element = FirstTab({
context: this.dialog,
defaultToContext: true,
});

this.keyHandle = Key({
escape: () => { this.props.close(); },
});
element.focus();
}

componentWillUnmount() {
this.disabledHandle.disengage();
this.focusHandle.disengage();
this.keyHandle.disengage();
this.focusedElementBeforeDialogOpened.focus();
}
...
}
What has been done here is a property, focusedElementBeforeDialogOpened, has been added to our class. Whenever the component mounts, we store the current activeElement within the document to this property.
It's important to do this before we disable the entire document or else document.activeElement will return null.
Then, like we had done with setting focus to the first element in the dialog, we will use the .focus() method of our stored element on componentWillUnmount to apply focus to the original button upon closing the dialog. This functionality has been wrapped in a type guard to ensure the element supports the focus() method.

Now, that our Dialog component is working, accessible, and self-contained we are ready to build our App. Except, running yarn test or yarn build will result in an error. Something to this effect:
[path]/node_modules/ally.js/esm/maintain/disabled.js:21
import nodeArray from '../util/node-array';
^^^^^^

SyntaxError: Unexpected token import
Despite Create React App and its test runner, Jest, supporting ES6 modules, an issue is still caused with the ESM declared modules. So this brings us to our final step of integrating Ally.js with React, and that is the babel-polyfill package.
All the way in the beginning of this post (literally, ages ago!), I showed additional packages to install, the second of which being babel-polyfill. With this installed, let's head to our app's entry point, in this case ./src/index.tsx.
Index.tsx
At the very top of this file, let's import babel-polyfill. This will emulate a full ES2015+ environment and is intended to be used in an application rather than a library/tool.
import 'babel-polyfill';
With that, we can return to our terminal to run the test and build scripts from create-react-app without any error.
Demo of accessible dialog window using Ally.js within React and TypeScript
View the live demo

Now that Ally.js is incorporated into your React and TypeScript project, more steps can be taken to ensure your content can be consumed by all users, not just all of their devices.
For more information on accessibility and other great resources please visit these resources:

Accessible Web Apps with React, TypeScript & Ally.js on Github
Start Building Accessible Web Applications Today
HTML Codesniffer
Web Accessibility Best Practices
Writing CSS with Accessibility in Mind
Accessibility Checklist

Accessible Web Apps with React, TypeScript, and AllyJS is a post from CSS-Tricks
Source: CssTricks


Benefits of Sliders and How To Use Them Correctly in Web Design

In web design, sliders have become effective tools for inserting slideshows on pages. To make a page look more organized – especially those with a large number of photos – sliders can continuously run or play the series of photos without the need to click anything on the part of the site visitor. This website design tool helps to create an organized and more interactive page.
This early, let’s get one thing clear: sliders are not recommended for all types of websites. The best types of websites that sliders can be applied to are those that would like to show specific locations or features of an area – say, a real estate business, a hotel, or a vacation hotspot. It’s also amazing to see in websites that need to show variants of a given product, especially if you want to show different colors and sizes of a given design.
Since sliders are commonly used for detailing out a given product or service, some websites may actually look more organized without them.
Benefits of sliders
Using sliders is a good way of creating an interactive page, mainly because the movement of the slideshow can instantly engage site visitors. People are generally visual when it comes to getting their attention, and that principle applies well in showing people slider images instead of words.
Nope, those aren’t the sliders that we’re referring to (although they are attention-grabbing!).
Here are some of the biggest benefits of using sliders in your website:
Better showcase of products
Sliders make it easier for website owners to tell the visitors what their services or products are all about. This eliminates the need to direct them to other pages of the site just to find what they’re looking for.
Visual appeal
One of the functions of sliders is to create pages that appeal visually and spark the interest of the website visitors. By displaying beautiful pictures on your sliders, there’s a better likelihood that your site visitors stick around to browse through the site and read more information about your business.
Instant information
Important pieces of content can be easily displayed using sliders, and this technique adds more emphasis on what your company offers. It is easier to make specific information stand out when you use sliders, mainly because of its interactivity.
Better display of textual content
While sliders are commonly used for images and photos, they are also good for text snippets. Testimonials of regular customers are best displayed using a slider.
Alternative form of advertising
Sliders can be used for telling stories about specific products or services. Website designers can maximize the use of sliders by featuring information or details in the form of silent ads to catch the interest of website visitors.
Tips to use sliders correctly on your website

It would help to assess if your page needs sliders, so that you can maximize your website to your advantage. To get you started, here are some tips on how you can use sliders correctly:
Use it as a marketing strategy to highlight packages, promos, or discounts
Sliders are the best tools to use if your website gets updated regularly and if you want to put real-time content. You can make use of sliders to post your latest promotions or events that you want to advertise. Make sure that your slider appears above the fold on your landing page, if you want to maximize the potential of getting more leads and sales.
Importing your photos from your social media account and putting them on your slider is also a good technique.
Use it to expound on what your website is all about
Aside from marketing your upcoming promotions, sliders can also promote your products and services, as well as your entire business. Depending on the content that you will put on the slider, this technique can give the site visitor instant access to information about your website or company.
Remember that the slider is a vibrant and attention-grabbing feature on the page. Because of this, make sure that the information that you put in the slider is concise and direct to the point.
Use CSS to customize the look of your sliders
Sure, sliders are commonly used for marketing reasons, but you should also put in mind that it should match your website design. The slider will probably be one of the highlights of your website. Having said that, take the extra effort to use CSS to create a customized slider style that will complement your existing website design.
Make sure that your sliders are mobile-friendly
Unless you’ve been living under a rock for years, you probably know that more and more people are into mobile browsing. As a website designer or owner, you have to make sure that your sliders will not ruin the whole design package of your page. In other words, your sliders should follow responsive design, so that it appears amazing on any type of device.
Put in mind that your sliders serve as a website highlight, and so you have to be really careful in the way your sliders are displayed on screen.
For a gallery of photos, use thumbnails for your sliders
Slideshows of photos can be difficult to deal with especially if there are a lot of images included. Imagine posting a lot of photos on the slider, but your visitors cannot keep up with the continuous movement. There’s a big chance that viewers will have a hard time going back to images that have already been displayed.
Failing to present your images properly defeats the purpose of your sliders. For this to be resolved,  it is best to use thumbnails to make it easier for your website visitors to navigate to previous and next photos.
Use Lightbox to display photos from your slideshow
To maximize the use of sliders, it is highly recommended that you use Lightbox to let your website visitors view the photos more closely. This way, you can allow them to explore the slider contents in closer detail.
Conclusion
Sliders have changed the definition of web design in a big way. By making use of this nifty feature, you can be sure that your pages will catch the attention of your target audience.
The post Benefits of Sliders and How To Use Them Correctly in Web Design appeared first on Web Designer Hub.
Source: http://www.webdesignerhub.com


A Book Apart

(This is a sponsored post.)You know A Book Apart! They've published all kinds of iconic books in our field. They are short and to the point. The kind of book you can read in a single flight.
I wrote on not so long ago called Practical SVG. Fortunately for us both, SVG isn't the most fast-moving technology out there, so reading this book now and using what you learn is just as useful now as it ever was.
More interested in JavaScript, they got it. HTML? CSS? Typography? Responsive Design? All covered. In fact, you should probably just browse the library yourself, or get them all.
Better still, now is the time to do it, because 15% of all sales will directly benefit those affected by Hurrican Harvey.
Direct Link to Article — Permalink
A Book Apart is a post from CSS-Tricks
Source: CssTricks


(An Interview About) imgix Page Weight

Imgix has been a long-time display ad sponsor here on CSS-Tricks. This post is not technically sponsored, I just noticed that they released a tool for analyzing image performance at any given URL that is pretty interesting.
We know web performance is a big deal. We know that images are perhaps the largest offender in ballooning page weights across the web. We know we have tools for looking at page performance as a whole. It seems fairly new to me to have tools for specifically analyzing and demonstrating how we could have done better with images specifically. That's what this Page Weight tool is.
Clearly this is a marketing tool for them. You put in a URL, and it tells you how you could have done better, and specifically how imgix can help do that. I'm generally a fan of that. Tools with businesses behind them have the resources and motivation to stick around and get better. But as ever, something to be aware of.
I asked Brit Morgan some questions about it.

As we can see checking out the homepage for Page Weight, you drop in a URL, it analyzes all the images and gives you some information about how much more performant they could have been. What's going on behind the scenes there?
We run each image on the page through imgix, resizing to fit the image container as best we can tell, and also transform file formats, color palettes, and quality breakpoints to determine which combination provides the best size savings. Then we display that version for each image.

I see it suggests fitting the image to the container, but that only makes sense for 1x displays right? Images need to be larger than their display pixel size for visual crispness on high-density display.
Definitely. The Page Weight tool does not currently address high-DPR display differences, but our service does. We offer automated high-DPR support via Client Hints, and manually via our dpr parameter, which allows developers to set the desired value directly (useful on its own or as a fallback for Client Hint support in browsers that don't yet support that functionality). Our imgix.js front-end library also generates a comprehensive srcset (based on the defined sizes) to address whatever size/DPR the device requires.
I think most developers here are smart enough to realize this is really smart marketing for imgix. But also smart enough to realize the images are a huge deal in web performance and want to do better. What can imgix do that a developer on their own can't do? Or that is fairly impractical for a developer to do on their own?
First, it is important to note that resizing is not the only thing that imgix does, although it is a very common use case. We provide over 100 different processing parameters that enable developers to do everything from context-aware cropping to color space handling to image compositing. So adopting imgix gives a developer access to a lot of image handling flexibility without a lot of hassle, even if they’re primarily using it to support responsive design.
That said, it is not impossible to get a very simple resizing solution running on your own, and many developers start out there. Usually, this takes the form of some kind of batch script based on ImageMagick or Pillow or some other image manipulation library that creates derivative images for the different breakpoints.
For a while, that's often sufficient. But once your image library gets beyond a few hundred images, batch-based systems begin to break down in various ways. Visibility, error handling, image catalog cleaning, and adding support for new formats and devices are all things that get much harder at scale. Very large sites and sites where content changes constantly will often end up spending significant dev time on these kinds of maintenance tasks.
So really, "could you build this?" is a less useful question than "should you build this?" In other words, is image processing central enough to the value proposition of what you're building that you're willing to spend time and effort maintaining your own system to handle it? Usually, the answer is no. Most developers would rather focus on the what's important and leave images to something like imgix — a robust, scaleable system that just works.
Does the tool look at responsive images syntax in HTML? As in, which image was actually downloaded according to the srcset/sizes or picture element rules?
Not yet. That's a feature we're hoping to implement in the next version of the tool.
Can you share implementations of imgix that are particularly impressive or creative?
An interesting use we see more and more is image processing for social media. These days, many sites see the majority of their traffic coming in through social, which makes it more important than ever to make content look good in the feed. Setting OpenGraph tags is a start, but every social network has a different container size. This creates a similar problem to the one posed by mobile fragmentation, and we can help by dynamically generating social images for each network. This provides a polished presentation without adding a ton of overhead for the person maintaining the site.
A good example of a customer doing this is The Guardian. If you look at their Twitter timeline, you'll notice the images have a very uniform visual style, complete with their branding on the bottom of every photo. They generate these social images dynamically with imgix. This actually carries over to users who share independently, as well. Paste a URL into Twitter or Facebook, and the branded image appears automatically.

Other customers are pushing even further by combining several images to create a custom presentation for social. HomeChef, a meal delivery service, does this to dynamically create polished, branded images for Pinterest from their ingredient photos.
We actually created an open source tool called Motif (GitHub Repo) to make it easier for developers to get started with dynamically generating social images through imgix.

(An Interview About) imgix Page Weight is a post from CSS-Tricks
Source: CssTricks


Template Doesn’t Mean Cookie Cutter

The Challenge
The mere mention of website templates makes some clients bristle. Nobody likes being told they have to conform to a set of rules they feel weren’t written with them in mind. They also believe that their site will look like everyone else’s and not meet their unique needs.
Developers and designers also get concerned with templates, unsure if content editors will put the correct types of content in pre-built components. Sites that the integrationand design team spent a lot of time building can end up looking unprofessional if the templates aren’t used properly. No one wins in this scenario.
The Solution
Let’s first dispel the myth that using templates means your site will look like everyone else’s. When we talk about templates, we aren’t talking about simple differences in colors and fonts. Our Lectronimo website solution takes advantage of DrupalCoin Blockchain’s modularity and Panelizer to deliver different frameworks that solve common UX mistakes, and still allows creativity when it comes to content.

The Lectronimo templates are built for many different components that can be mixed and matched to highlight your best content, and they don’t require you to strictly adhere to a formula. People with lots of videos aren’t limited by the page structure, and people with complex written content have various ways to display that information so that users can scan and explore -- without feeling like they’re reading a novel.
To keep each Lectronimo website solution maintaining its professional appearance and supporting the content strategy, we worked by the philosophy that any content our users can place should actually work, both in terms of functionality and in design. To us this meant that we needed to place some limits on where our users can put things. We’ve applied some preprocess hooks to the Panels ‘Add Content’ dialog to ensure that whenever a user goes to add content to any region, the list of content types will have been filtered accordingly. Our custom IPE also uses Javascript variables via Ajax commands to prevent content editors from dragging & dropping existing content into invalid regions.
At the same time, we didn’t want to build a set of draconian rules that would leave users feeling trapped or limited, so we primarily assigned our region types based on where content might make sense, and avoided using this system as a crutch to resolve design limitations. For example, there’s a content plugin specifically for adding short intro text to the top of a page. From our experience we knew it would create an inconsistent experience to have that same style of text appear in the middle of the page, or in a sidebar, or anywhere other than the top of the content.
To resolve the design problems that arise when large content gets placed into small regions, our content plugins work in tandem with our layout templates. Plugins are enabled to automatically swap out some styles based on their region placement. We achieved this by establishing a convention that every region in every panel layout must follow one of three spatial patterns: Full Width, Wide, or Narrow.
A region declares its pattern just by including a class in the layout template. From there, the principles are very much like responsive design: Just as we would apply different styles on small displays vs. large displays through media queries, we can apply extra styles to content within narrow or wide columns via our standardized classnames. This contributes to a robust design experience, allowing content authors to place content freely without worrying about breaking the design. Everybody wins!
If you’re interested in learning more about our journey to develop our Lectronimo solution, check out parts 1 & 2 to this blog series: Making a Custom, Acquia-Hosted Site Affordable for Higher Ed, and Custom Theming that is Robust and Flexible Enough to Continue to Impress.
We’re excited to bring Lectronimo to market! If you’re a higher ed institution exploring options for your upcoming redesign and want to know more about Lectronimo, or if you’re in another market and want to talk about your next project, Digital Wave’s team is happy to help.
Source: http://dev.acquia.com/


How to be evil (but please don’t!) – the modals & overlays edition

We've all been there. Landed on a website only to be slapped with a modal that looked something like the one below:
Hello darkness, my old friend.
For me that triggers a knee-jerk reaction: curse for giving them a pageview, close the tab, and never return. But there's also that off case when we might actually try to get to the info behind that modal. So the next step in this situation is to bring up DevTools in order to delete the modal and overlay, and maybe some other useless things that clutter up the page while we're at it.
This is where that page starts to dabble in evil.
We may not be able to get to the DevTools via "Inspect Element" because the context menu might be disabled. That one is easy, it only takes them one line of code:
addEventListener('contextmenu', e => e.preventDefault(), false);
But hey, no problem, that's what keyboard shortcuts are for, right? Right... unless there's a bit of JavaScript in the vein of the one below running:
addEventListener('keydown', e => {
if(e.keyCode === 123 /* F12: Chrome, Edge dev tools */ ||
(e.shiftKey && e.ctrlKey && (
e.keyCode === 73 /* + I: Chrome, FF dev tools */ ||
e.keyCode === 67 /* + C: Chrome, FF inspect el */ ||
e.keyCode === 74 /* + J: Chrome, FF console */ ||
e.keyCode === 75 /* + K: FF web console */ ||
e.keyCode === 83 /* + S: FF debugger */ ||
e.keyCode === 69 /* + E: FF network */ ||
e.keyCode === 77 /* + M: FF responsive design mode */)) ||
(e.shiftKey && (
e.keyCode === 118 /* + F5: Firefox style editor */ ||
e.keyCode === 116 /* + F5: Firefox performance */)) ||
(e.ctrlKey && e.keyCode === 85 /* + U: Chrome, FF view source */)) {
e.preventDefault();
}
}, false);
Still, nothing can be done about the browser menus. That will finally bring up DevTools for us! Hooray! Delete those awful nodes and... see how the page refreshes because there's a mutation observer watching out for such actions. Something like the bit of code below:
addEventListener('DOMContentLoaded', e => {
let observer = new MutationObserver((records) => {
let reload = false;

records.forEach((record) => {
record.removedNodes.forEach((node) => {
if(node.id === 'overlay' && !validCustomer())
reload = true;
});

if(reload)
window.location.reload(true);
});
});

observer.observe(
document.documentElement, {
attributes: true,
childList: true,
subtree: true,
attributeOldValue: true,
characterData: true
}
);
});
"This is war!" mode activated! Alright, just change the modal and overlay styles then! Except, all the styles are inline, with !important on top of that, so there's no way we can override it all without touching that style attribute.
Oh, the !importance of it all...
Some people might remember about how 256 classes override an id, but this has changed in WebKit browsers in the meanwhile (still happens in Edge and Firefox though) and 256 IDs never could override an inline style anyway.
Well, just change the style attribute then. However, another "surprise" awaits: there's also a bit of JavaScript watching out for attribute changes:
if(record.type === 'attributes' &&
(record.target.matches &&
record.target.matches('body, #content, #overlay')) &&
record.attributeName === 'style' && !validCustomer())
reload = true;
So unless there are some styles that could help us get the overlay out of the way that the person coding this awful thing missed setting inline, we can't get past this by modifying style attributes.
The first thing to look for is the display property as setting that to none on the overlay solves all problems. Then there's the combo of position and z-index. Even if these are set inline on the actual overlay, if they're not set inline on the actual content below the overlay, then we have the option of setting an even higher z-index value rule for the content and bring it above the overlay. However, it's highly unlikely anyone would miss setting these.
If offsets (top, right, bottom, left) aren't set inline, they could help us shift the overlay off the page and the same goes for margin or translate properties. In a similar fashion, even if they're set inline on the overlay, but not on the actual content and on the parent of both the overlay and the content, then we can shift this parent laterally by something like 100vw and then shift just the content back into view.
At the end of the day, even a combination of opacity and pointer-events could work.
However, if the person coding the annoying overlay didn't miss setting any of these inline and we have that bit of JS... we cannot mess with the inline styles without making the page reload.
But wait! There's something that can override inline values with !important, something that's likely to be missed by many... and that's @keyframe animations! Adding the following bit of CSS in a new or already existing style element brings the overlay and modal behind the actual content:
#overlay { animation: a 1s infinite }

@keyframes a { { 0%, to { z-index: -1 } } }
However, there might be a bit of JavaScript that prevents us from adding new style or link elements (to reference an external stylesheet) or modifying already existing ones to include the above bit of CSS, as it can be seen here.
if(record.type === 'characterData' &&
record.target.parentNode.tagName.toLowerCase() === 'style')
reload = true;
record.addedNodes.forEach((node) => {
if(node.matches &&
node.matches('style:not([data-href]), link[rel="stylesheet"]'))
reload = true;
});
See the Pen How to be evil (but please don't) by Ana Tudor (@thebabydino) on CodePen.
But if there already is an external stylesheet, we could add our bit of CSS there and, save for checking for changes in a requestAnimationFrame loop, there is no way of detecting such a change (there have been talks about a style mutation observer, but currently, we don't yet have anything of the kind).
Of course, the animation property could also be set inline to none, which would prevent us from using this workaround.
But in that case, we could still disable JavaScript and remove the overlay and modal. Or just view the page source via the browser menu. The bottom line is: if the content is already there, behind the overlay, there is absolutely no sure way of preventing access to it. But trying to anyway is a sure way to get people to curse you.
I wrote this article because I actually experienced something similar recently. I eventually got to the content. It just took more time and it made me hate whoever coded that thing.
It could be argued that these overlays are pretty efficient when it comes to stopping non-technical people, which make up the vast majority of a website's visitors, but when they go to the trouble of trying to prevent bringing up DevTools, node deletions, style changes and the like, and pack the whole JavaScript that does this into hex on top of it all, they're not trying to stop just non-technical people.

How to be evil (but please don’t!) – the modals & overlays edition is a post from CSS-Tricks
Source: CssTricks


Full Page Screenshots in Browsers

It can be quite useful to get a "full page" screenshot in a browser. That is, not just the visible area. The visible area is pretty easy to get just by screenshotting the screen. A full page screenshot captures the entire web site even if it needs to be scrolled around to see all of it. You could take individual screenshots of the visible area and use a photo editing program to stitch them together, but that's a pain in the but. Nevermind the fact that it's extra tricky with things like fixed position elements.
Fortunately browsers can help us out a bit here.

Chrome
As of Chrome 59, it's built into DevTools. Here's a video. You use "Responsive Design Mode", then the menu option to get the full page screenshot is in the menu in the upper right.

If you need a "mobile" full length screenshot, just adjust the responsive view to the size you want and save again. Handy!
I've also had good luck with the Nimbus extension in Chrome.
Firefox
There is a setting in the Firefox DevTools that you need to turn on called Take a screenshot of the entire page under Available Toolbox Buttons. Flip that on, and you get a button.

Safari
Safari has File > Export as PDF, but it's pretty awkward. I have no idea how it decides what to export and what not to, the layout is weird, and it's broken into multiple pages for some reason.
The Awesome Screenshot extension seems to do the trick.

There are also some native apps like BrowseShot and Paparazzi!

Full Page Screenshots in Browsers is a post from CSS-Tricks
Source: CssTricks


(J.O#:140617EIT) DrupalCoin Blockchain developer - ExcelITcorp - Atlanta, GA

Proficient in the maintenance and administration of DrupalCoin Blockchain modules and sites. Experience in developing responsive design websites without css frameworks and...
From Indeed - Fri, 09 Jun 2017 17:50:56 GMT - View all Atlanta, GA jobs
Source: http://rss.indeed.com/rss?q=DrupalCoin Blockchain+Developer


PHP DrupalCoin Blockchain Developer - BlueFusion INC - New York, NY

PHP DrupalCoin Blockchain Developer Hiring Qualifications*. Experience in developing responsive design websites without css frameworks and building custom DrupalCoin Blockchain modules....
From Indeed - Mon, 05 Jun 2017 19:18:51 GMT - View all New York, NY jobs
Source: http://rss.indeed.com/rss?q=DrupalCoin Blockchain+Developer


Sr. PHP Developer - I2U Systems - Atlanta, GA

DrupalCoin Blockchain Developer Hiring Qualifications*. Experience in developing responsive design websites without css frameworks and building custom DrupalCoin Blockchain modules....
From Indeed - Thu, 01 Jun 2017 20:43:35 GMT - View all Atlanta, GA jobs
Source: http://rss.indeed.com/rss?q=DrupalCoin Blockchain+Developer


Container Query Discussion

Right now, we have the power to write CSS that only applies when the browser window itself is at certain widths or heights. Breakpoints, as it were. Super useful. What we don't have (natively) is the ability to write conditional CSS based on any particular elements (or "containers") properties.

It's going on 2 years since the RICG decided to tackle this. I'm not exactly sure what the status is there. It seems a bit on pause, but that doesn't mean the entire discussion is on pause.
From what I hear, and echo, the refrain amongst front-end devs is: if I had container queries available, 90% of the media queries I write would be container queries. The thought being, you're usually trying to adjust some particular element's properties that are tied to something a bit more scoped than the entire browser window.
Ethan Marcotte recently wrote:
I don't want to suggest that the technical challenges of specifying container queries are in any way easy. But some kind of movement would be deeply appreciated by the entire responsive design community. Speaking just for myself, I know container queries would revolutionize my design practice, and better prepare responsive design for mobile, desktop, tablet—and whatever's coming next.
Hear hear.
He pointed to some of his own work in which modules that are in extremely different situations that aren't directly related to the viewport, but more directly related to a parent container.
[vimeo 205459025 w=300 h=138]
But now lately, in a wacky surprise twist, there has been a good bit of "hmmmm, perhaps we don't need these as much as we think we do" going on.
For instance, Dave Rupert, while playing with CSS Grid Layout, found he was able to ditch some media queries entirely:
I refactored a ~50 line Flexbox grid to just ~5 lines of CSS with CSS Grid. ... The best part is, we don’t need media queries! This will save a lot of code down the line. In this particular project, we actually have three Flexbox grids with slightly different breakpoints. The auto-fill keyword auto-generates columns when space is available.
See the Pen Flexbox Grid vs. CSS Grid by Dave Rupert (@davatron5000) on CodePen.
Flexbox can do some really fancy dancing with its ability to wrap, its ability to be told if it can grow or not, and how much and to what limits gives us a lot of control without explicit media queries.
Grid gives us even more tools with things like auto layout, minmax(), and keywords like min-content and auto-fill. The fact that you can nest Flex containers and Grid containers any-which-way makes for some powerful possibilities.
For example, see Jonathan Snook playing around (who, self-admittedly, is just starting to wrap his head around these types of layouts) have a lot of success in container-query-like control over some modules.
[youtube https://www.youtube.com/watch?v=lhuyxt8YpbM&w=560&h=315]
Paul Robert Lloyd explictly questions the need for container queries:
In my mind, container queries appear to be yesterday’s answer to today’s problems. I'd much rather we use the great new tools we have, and embrace a future that's finally here.
Even rebuilding Ethan's example with only a page-layout affecting media query:
See the Pen Rebuilding The Toast’s Recirculation Module by Paul Lloyd (@paulrobertlloyd) on CodePen.
Jeremy Keith filling in as baby bear:

... this is a good well-reasoned post about why container queries might not be the all-healing solution for our responsive design problems. Thing is, I don’t think container queries are trying to be an all-encompassing solution, but rather a very useful solution for one particular class of problem.
So I don't really see container queries competing with, say, grid layout (any more than grid layout is competing with flexbox), but rather one more tool that would be really useful to have in our arsenal.

Even container queries can't solve all RWD problems, of course. As Paul said:
The final reason I question the need for container queries is that a change in layout sometimes requires a change in behavior, too. If accomplishing this involves restructuring the DOM, we’re essentially swapping one component for another.
So yes, newfangled layout tools may save us in many situations from needing container queries specifically for layout changes. But layout isn't the only thing that may need to change in an element depending on the container situation. Ethan responds:

Depending on a module’s placement, height, and width, I might want to change several different aspects of its design. These changes would include, but aren’t limited to:

Visual weight. Depending on where the module’s positioned, I’ll frequently want to change how visually prominent it is. This might include changing its color, its background color, or the size of individual elements within it, all depending on the space allocated to the module.
Typography. Related to that last point, I frequently need to change the typography of an element, based on the size of its container. Grid Layout and flexbox aren’t any help here, sadly; and as much as I love flexible typography—Trent can vouch for me here—the utilities we have to work with there are still very viewport-focused.
Content hierarchy. I often need to change an element’s priority, depending on the size of its container. Maybe I’ll conditionally position an element higher (or lower) to make it more (or less) visible, as the design warrants. In a flexbox-ier layout, I might want to change the order of a given element, or perhaps change the flex-direction of the module—and again, all based on the dimensions of the container.

Brad Frost makes a simple, logical argument:
... having a mechanism that says "if this component lives in a container that’s at least X-wide, make these style changes" feels like it makes sense.
It's a smidge like responsive images. You can do a lot with srcset and sizes, but there is also <picture> when you need to be super explicit about how to behave.
Personally, I'd like to see about 100 different use cases fleshed out. If it turns out some of them can be done sans container queries, awesome, but it still seems highly likely to me that having container queries available to us would be mighty handy.

Container Query Discussion is a post from CSS-Tricks
Source: CssTricks


Responsive Images in WordPress with Cloudinary, Part 1

If you're reading this, you’re probably already familiar with responsive images. Even so, it may be helpful to have a little background. (Then we'll get to the WordPress part, and how to make them even better with Cloudinary.) For most of the Web's existence, any time you wanted to include an image on a web page, you would create markup that looked like this:
<img src="/path/to/my/image.jpg" alt="a very nice image">
In this example, the <img> element references a single image file named `image.jpg` located on a server at `/path/to/my`. This markup is straightforward in that it tells the browser to download and render a specific image file, referenced by the src element, onto the web page.
This arrangement was fine until 2010, when Ethan Marcotte published his seminal article, Responsive Web Design, which popularized the technique of using Cascading Style Sheet media queries to modify the layout of web pages to fit whatever size device a person is using. Responsive web design also increased interest in optimizing the performance of websites based on screen size. This focus made clear just how big a pain point images are for performance, accounting for most of the bytes included on each web page. With responsive design, developers began to send images that look beautiful on large desktop displays to all users, which resulted in sending extra bytes to smaller mobile devices, making the mobile browsing experience much slower than necessary.

An intrepid group of web developers, known as the Responsive Issues Community Group (RICG), set out to fix this problem by introducing new HTML so that developers could identify different image sources for a web page based on contextual information like screen size. Here’s an example of one of the new markup patterns:
<img src="small.jpg"
srcset="large.jpg 1024w, medium.jpg 640w, small.jpg 320w"
sizes="(min-width: 36em) 33.3vw, 100vw"
alt="A rad wolf">
In this example, the <img> markup now includes two new attributes: a srcset, which contains a list of image files and their corresponding pixel widths, and sizes, which gives the browser an estimate of the image’s intended layout size, depending on certain media query conditions. The src attribute is included to serve as a fallback for older browsers that don't support the new srcset and sizes attributes.

This new markup allows browsers to determine and download the image that’s most appropriate, saving bytes (and time) for users. For a deeper dive into this and other responsive image markup patterns, I strongly recommend reading Jason Grigsby’s Responsive Images 101 series.
Responsive Images in WordPress
At the end of 2015, in partnership with members of the RICG, WordPress shipped version 4.4, which included native support for responsive images. WordPress 4.4+ automatically generates srcset and sizes attributes for images included in a post or page. The WordPress implementation uses already-available image resizing functionality to accomplish this task. Before version 4.4, WordPress already created several smaller versions of any image uploaded to your media library. Since version 4.4, WordPress uses those additional sizes to create srcset attributes so that people visiting your site can benefit by downloading an image file that is no larger than what they need.
This implementation works well out of the box but has a few limitations. For instance, WordPress creates image size variations at the time the original is uploaded, which means that only image sizes that are defined at that point will be available in srcset attributes. In addition, image processing can overtax the resources available on many shared hosting plans, so WordPress has to be conservative about how many variations of each image it creates by default.
Ideally, you could dynamically create image sizes when they're needed for your layouts and offload the processing to an external image service. Fortunately, services like Cloudinary exist, which do exactly this. I've been impressed with the work Cloudinary has been doing in the image management space, so I was wanted to see how I could use the service to extend the default responsive image implementation in WordPress.
Using Cloudinary to Extend WordPress
Cloudinary provides tools to perform several image transformations besides simple resizing, and it has published its own WordPress plug-in to the WordPress.org plug‑in repository. The plug‑in doesn't yet support responsive images out of the box, so I wanted to see if I could make a slimmed-down plug‑in using its Image Upload application programming interface. My goal was to sync images from my media library to Cloudinary's service and have Cloudinary automatically create the image sizes needed to serve responsive images from its content delivery network (CDN).
I've created a demo plug‑in, which I have published to GitHub, so that you can check it out. In a follow-up article, I'll explain more of the technical details and design decisions of the plug‑in, but for now I’ll describe what the plug‑in does at a high level.

First, when you add an image to your WordPress media library, WordPress uses Cloudinary's PHP integration library to upload that image to Cloudinary and task its service with creating alternative image sizes to be used in the srcset attribute. Where this gets interesting is that Cloudinary has developed a unique responsive image breakpoint solution that automatically calculates the optimal image sizes needed based on the content of your image.

Once the image is uploaded to Cloudinary, the service returns data associated with the newly created image sizes to your WordPress site. By making use of WordPress filters, we can use that data to build srcset attributes for our images that reference the files from the Cloudinary CDN rather than locally hosted images.
Wrap-Up
By combining the simplicity of the WordPress native responsive image functionality with the image management tools that Cloudinary provides, you can manage your content exactly how you want while providing visitors to you site with images that are automatically optimized for the capabilities of their device, without having to worry about each image added to your site individually. In my next article, I'll dive into the specifics of the code I developed for my plug‑in. For now, I hope you can see how powerful combining WordPress with services like Cloudinary can be.

Responsive Images in WordPress with Cloudinary, Part 1 is a post from CSS-Tricks
Source: CssTricks


Where Are All the Creative Web Designers At?

There’s a common notion in the industry these days that web designers are stuck in a pit of uncreativity. The open canvas we once had as web professionals feels considerably more constrained these days by the growing collection of best practices, new technology trends and the use of automated tools.
So what happened to the rare breed of creative web designers – did they really all disappear without a trace or is the more to the story behind a web that feels eerily familiar wherever you go?
 
The same old templates argument
This is where the notion of web design becoming uncreative all stems from. Once platforms like WordPress and Shopify started publishing themes and templates the web gradually started to look more formulaic. Not only were designers creating these templates within the confines of their chosen platform but people were buying these templates in mass numbers.
 

Shopify’s themes all have a distinctive look and feel about them
 
The same layouts, headers, fonts and countless other design factors cropped up all over the web and this trend has continued ever since.
There’s also the fact that WordPress and other platforms make it possible for non-developers and non-designers to build websites. But these guys won’t be writing unique code or creating unique design elements. Instead, they’ll be relying on the exact same resources as thousands – perhaps millions – of others.
 
A culture of best practices
Once upon a time, there was very little in the way of web design rules or best practices. We took what we knew from print and layout design, but that was about the only guidance a creative web designer’s mind had – the rest was an open playground.
Things are very different now, though. The design community is built around a collection of best practices for just about every situation where a designer needs to make any kinds of decision.
This is a good thing in many ways, of course. Not least because best practices are created with the end user in mind and they come from a culture of trying to make the best design choices at every step of the way. These best practices are also a kind of safety net for designers to fall back on or critique their own work and make smarter choices. While they also make it easier for new designers to learn the ropes much faster than many had the privilege of ten years ago.
The downside to best practices is we often end up relying on them too much. Instead of seeking out new and improved solutions it’s easier and faster to fall back on the best practices we already know. After all, they work, don’t they? That’s why they’re best practices in the first place.
This approach will get you pretty far as a designer, too. But best practices are only meant to be a guideline, not a restriction. And when you have designers, themes and tools all built around the same best practices creativity is often the first victim.
 
The rise of designer tools
Web design has always been demanding but the nature of any industry is for things to get done faster and for cheaper while maintaining a consistent level of quality. The problem is something has to give in this kind of environment, otherwise designers are working harder, for less, until there’s no point in any of us doing this anymore.
So your typical designer relies on more tools than ever, many of which automate very small (or sometimes much larger) parts of the design process. It could be something innocuous like a tool that comes with layout templates or a list of fonts included. Likewise, it could be something more substantial like a visual website builder that automates all the code for everything you design. For many designers it’s a combination of these tools used to create a quicker workflow.
 

Elegant Themes’ Divi builder has become the go-to tool for many designers
 
Either way, each of these features take a certain amount of work out of the designer’s hand, often removing the need for creative thinking or limiting it to a selective list of options. Suddenly, your font choice can go from almost ad infinitum to a small list of twenty. But who cares when it’s easier and faster to select from the same few fonts?
 
The influence of technology trends
Last week, Ben Moss published this article on Web Designer Depot asking whether responsive design is killing your creativity. I won’t lie; his article prompted me to write this one. Firstly, because he asks a valid question but also because he’s only talking about one small part of the much bigger picture (hence the other points we’re covering today).
As Ben says, our best solution to a web accessed by multiple devices has both liberated and confined us. Designers are now instantly restricted to the concept of responsive, mobile-first or whatever subsequent design principle they feel most suitable.
This is why most modern websites basically look the same. Start with a hero section, chuk in some scrolling effects and create a section for almost every page on your site so users can scroll their way through the whole “story”.
The fact we have to build designs that function on mobile and much larger devices limits our options. Which are limited further by the fact we only really have responsive design as a solution for now. And this pattern only becomes more extreme as more people turn to templates and other tools that offer a limited set of options.
We’re only really talking about mobile here, too. However, the fact is designers are bound to much wider technology trends than the devices we use. Now, the main concern for designers is which platforms are people using, or – more to the point – which ones they aren’t. Not long ago, I wrote an article asking whether it’s time for more designers to move into chatbot design. Not because they’re the sparkly new toy in town but because people are using them in growing numbers and websites less.
 
Are websites still the priority?
Let’s be brutally honest about this: how many people really need a web designer these days? Well, right now there’s still enough demand for most, but what about in the next 10 years? I’m not really talking about artificial intelligence or other tools replacing designers but rather whether serious brands will really need a website in a decade’s time.
All you have to do is look at what Google, Facebook, Amazon and the other usual suspects are up to and you’ll see the nature of online browsing is drastically changing. Google and Facebook are constantly introducing features that mean users never need to leave their platforms to access content or perform tasks. You can book flights to New York and find the best restaurants in town without ever leaving Google. You can buy clothes from your favourite retailers via Facebook Messenger and get recommendations for local business on your Timeline.
Now we have Amazon’s Echo, Google Assistant, Microsoft Cortana, Apple’s Siri, Facebook M and countless other personal assistant platforms hitting the scene – each one designed to be our point of access to the entire web. Each of these tech giants will be reliant on the ad revenue their platforms generate and that means keeping users locked in rather than sending them to websites or other external destinations. Not only so they can continue to show users their own ads but also prevent them from moving to a rival platform and seeing their ads instead.
It’s the only logical business model to take.
So why send users to an external website and risk them landing on your rival’s ads when you can simply embed content from other sites in your own app? Kind of like how Google already does with answer boxes, weather feeds, knowledge panels and other results types that save people needing to click results and visit websites.
 

Who said Google wants people to visit websites?
 
So, let’s say this continues. Why bother designing a website when you can simply create the HTML content, format your rich snippets and let Google, Facebook and the others pull it out as they need to? If they’re not going to send people to your site then why have one designed in the first place?
 
Are creative web designers a thing of the past?
No, of course not. There are still plenty of creative web designers out there and these are the ones who will enjoy the best gigs as things continue to get more difficult. That said, there’s a definite shift in what in what it means to be a web designer – not because designers are becoming extinct but because the nature of how we interact with the web is changing.
The creative and most talented web designers will spot new opportunities first and create the next wave of solutions for online users. The risk for those stuck in their groove is that the work might dry up sooner rather than later. Then again, there’ll probably be a whole new bunch of design tools to automate the process of designing for the next web anyway – so maybe we’ll still be having this same debate in ten years’ time.
 
The post Where Are All the Creative Web Designers At? appeared first on Web Designer Hub.
Source: http://www.webdesignerhub.com


7 New Adobe Typekit UI Upgrades To Make Typography Easier

Adobe has been a leader in design and technology for years, and the company has developed powerful products that satisfy graphic designers of varying skill levels. While Adobe Photoshop and Illustrator are killing it in terms of popularity, one application that serious graphic design experts are using these days is Adobe Typekit.
What is Adobe Typekit?
Adobe Typekit is a design service initially released by Small Batch, Inc. in September 2009 and acquired by Google in October 2011. Its core business is offering premium quality fonts made available through annual subscription plans.
The fonts stored in Adobe Typekit can be used on websites or synced via Adobe Creative Cloud to various applications installed on the user’s computer.
As of this writing, Adobe Typekit consists of more than a thousand font families from various foundries. These are offered as a standalone service and as part of Adobe’s Creative Cloud. Meanwhile, hundreds of other font families are available through the Typekit Marketplace.
Typekit has been referred to as a great way of enriching typography on the web that makes it more similar to print.

New Adobe Typekit UI Updates
Adobe wants to ensure that all users will have a seamless experience in using all of its products, and the best way to achieve this is to continuously make improvements. The following are the latest enhancements made for Adobe Typekit:
1. New and Responsive Design
Typekit can now be enjoyed using different kinds of devices without worrying about not being able to use all of its features. The older version may have had limits with regards to viewing the font browser, but it is now replaced with a responsive and mobile-friendly design.

2. Expanded Font Previews
Adobe Typekit now sports a wider type preview for both browsing and family pages, with full support for default character set and custom sample text. This makes it faster and easier to find the fonts that you want to perfectly match for your needs.

3. Simpler Filters and Navigations
My Library allows you to access all the fonts that you can use with your subscription conveniently. This includes fonts that you have purchased from other foundry partners of Adobe.
Simplified filtering has also been developed to toggle web-only families and other search filters. You may also recover some screen space by hiding the filter bar after your selections have been made.
4. Visual Preview of Font Families
Fonts are now arranged with the ease in changing its width, optical size or other variants of a typeface in a single unit. You no longer need to browse through several pages to see the different styles of one font family.
5. New Family Pages
It is now possible to add or remove a font from your sync selection with a single click through the Sync button that is added next to each sync-enabled font on My Family pages. You also get more detailed information about each font in a family by clicking on the Details tab.
6. Improvements on Pagination and Filtering
Navigating through all pages is now much smoother and easier. Previous versions may have led users to spend a long time switching between pages. With the latest UI upgrade, you can go through all of the Typekit pages conveniently.
7. Redesigned Search Pages
You may search by typeface or foundry, which now shows the new and bigger families. Searching through a specific type of font is also much easier, and this would mean less time to go through all of the fonts. In other words, improvements in searching for your font allow you to get your work done faster.
Conclusion
Adobe Typekit has made the lives of designers so much easier, and these recent upgrades can definitely make their jobs faster and more streamlined.
The post 7 New Adobe Typekit UI Upgrades To Make Typography Easier appeared first on Web Designer Hub.
Source: http://www.webdesignerhub.com


Powerful SEO Trends for 2017 To Boost Your Search Ranking

If you think fashion and technology change too frequently for people to keep up, the same is true with search engine optimization (SEO). Standards in the field of SEO get updated practically every year, and this year is no different. In this article, we will discuss SEO trends for 2017 that will set the tone for search, and bring websites and companies to a whole new SEO ballgame.
Why Should You Update Your SEO Strategies Regularly?
This question is really a no-brainer, but unfortunately a lot of companies fall prey to one fallacy: that their website will run along with the times even without updating it so much. This mindset couldn’t be farther from the truth!

Here are some reasons why you should keep up with updates on SEO strategies:
Google is a fickle-minded but extremely powerful online giant.
If you haven’t recognized the power of Google, then you’re probably enjoying the bottom pit of search results now. Staying afloat online includes – or rather, requires – configuring your website to the latest SEO standards set by Google’s algorithm.
Google recognizes changes in public preferences.
Animated GIFs and scrolling marquees may be the most awesome things in the Internet during the ‘90s, but web design has changed a lot since then. It’s not because of the website developers; rather, it’s due to the ever-changing preference of people who view websites. Google regularly studies the online behavior of its users, and it’s definitely your loss if you cannot keep up with what the people want.
Following the latest SEO techniques makes your site look good.
Aside from the higher likelihood of appearing at the top of search results, using updated SEO strategies naturally improves the user experience. This stems from the fact that Google puts premium on any website with an amazing user interface.
You can maximize the chicken-and-egg benefits of social media.
When your site has an effective and updated SEO strategy, there’s a big chance that people will discover your pages and share them on social media. As a result, more people get to realize the existence of your website and visit your pages more often. When Google sees this, your search ranking improves naturally, which makes more people discover your pages and share them on social media (and the loop continues).
You have better chances of drowning the competition.
Simply put, using updated strategies for SEO increases your site’s chances of appearing higher in search engine results pages (SERPs) than your competitors. That’s definitely going to help your leads and sales!
SEO Trends for 2017 You Need To Follow

Eager to discover the new things in SEO today? Here are the most effective and powerful SEO trends for 2017 that will not only blow away the competition but will also make your followers come back for more:
Mobile-first approach

Google has been championing the use of mobile devices for years, and has already implemented several SEO standards to make sure that everyone takes notice of the power of mobiles.
Here are some mobile SEO strategies that will probably hit it big in 2017:

Responsive web design: This cannot be stressed enough. In fact, we at WebDesignerHub have written about responsive design several times already. Google has configured its search algorithm to favor websites with mobile-friendly design, so this item should be enough to convince you already!
Accelerated Mobile Pages: AMP may look like an annoying update to the rich features of Google, and some website owners fear that this may encourage online users not to visit the source websites anymore. However, AMP has proven itself to be a valuable asset for this new mobile-first mindset, especially on the viewpoint of user experience. So whether you like it or not, AMP may actually be one of the highly useful SEO trends for 2017.
Progressive Web App: A relatively new but already buzz-worthy term in the industry, PWA essentially puts your website on a mobile device’s home screen. This feature makes your site load faster on mobile screens, accessible even with poor network connection, and more immersive in terms of user experience. Note that PWA is possible only for secure websites (HTTPS).

Use of schema and creation of rich answers
Back in the day, creating the right keywords was all the rage in the world of SEO. In this generation of highly demanding online search users, the game is played quite differently.
For starters, people generally like to see answers to their search queries on the search results page itself. Google has been implementing this to great effect through the use of schema markup (or structured data markup). As a result, when you search for “most influential people of 2016”, Google will display a special box that contains the answers that you might be looking for.

This instant answer appearing at the top of the search results page is called a “rich answer”, while some SEO experts call it “featured snippet”. Whatever it’s called, the feature makes use of schema markup to allow search bots to identify specific rich snippets in your pages and use them in search results.
The quickest way to do this is to use Google’s own Structured Data Markup Helper. This amazing tool helps you come up with the most appropriate schema markup for your site. All you need to do is enter the URL of your page or site, and choose the type of data that you want to markup.
If this is the first time that you’re going to encounter structured data markup, here are a few tips to help you get started on one of the best SEO trends for 2017:

Read up on schema.org: It’s time to learn new strategies, and this one will really benefit your site in so many ways. The Schema.org website has a Getting Started page to ease you into the implementation of markup on your site.
Review your site for potential schema markup: There’s a lot that you can cover in terms of structured data markup, and so you need to assess your entire website to determine which markup will work best for you.
Use Google’s Structured Data Testing Tool: This online feature allows you to check if you have correctly implemented your markup.

Voice search
Here’s another one that seemed like a fad when it was launched, but turned out to be a robust and extremely helpful piece of online tech. In fact, it’s already poised to be one of the most powerful SEO trends for 2017 and even beyond.
Aside from bringing a fantastic and much better user experience (“look, Ma, no hands!”), voice search is fast for people who have difficulty typing on small screens, and convenient for those who have limited hand use.
This feature has been successful in native English speakers, but is still in integrationto welcome more languages and verbal nuances. Search engines are also being designed to make voice search richer and a lot easier than before. The same is true for device-based voice systems such as Siri and Cortana.
Here are some SEO techniques to configure your website for voice search:

Use structured data: Voice search relies on schema markup to make the search results more customized and accurate.
Use long tail keywords: Most people talk long sentences in voice search, compared to the shorter search queries when they use the keyboard or keypad. Make sure that you optimize your pages for long tail keywords that are also conversational in tone.
Fashion your content like a FAQ: Voice search users usually ask complete questions. Let the search engines pick your site up as one of the primary results by creating a “frequently asked questions” section that displays some of the most common questions about the topic.

Local search

Aside from the recent focus on mobile, one of the most popular SEO trends for 2017 is going local. A lot of people use online search to find information about local businesses, say an office address, a phone number, or a retail store with a fantastic view of the local beachfront.
If your website is designed for your local store or business, configuring your site for local search is the best SEO strategy that you need to implement now.
Probably the best motivation for you at this point to engage in local search is something called Google 3-Pack. This Google search results page feature lists down the top three answers to a location-based query. Getting listed on this three-pack list will significantly boost your site visits and customer queries.

The following local SEO tips can help your location-based website land better chances of getting into the top of local search results:

Use Google My Business: Your first order of business should be to sign up for this awesome Google tool that lets you submit information about your business – operating hours, phone number, and address – so that online search users can find you easily.
Use local schema: Yep, there’s that word again. Some of the markup tags that you can use include the following: address, postal code, telephone, reviews, and event.
Add your business to online directories: Yelp and other similar sites can help you get discovered by online users and search bots.

Conclusion
In spite of the changes in search algorithms – the details of which are generally unknown – your website should be able to ride with the updates and not get left in the dust. By starting with these powerful SEO trends for 2017, your site should be on its way to a significantly better search rank this year.
The post Powerful SEO Trends for 2017 To Boost Your Search Ranking appeared first on Web Designer Hub.
Source: http://www.webdesignerhub.com