Curt Long Get Started
Welcome Back, ().
at
Has your work information changed?
Welcome
Please review the fields below for completeness and accuracy prior to submitting.
Welcome Back, ().
Has your work information changed?
Get Started
Welcome Back, ().
at
Has your work information changed?
Welcome
Please review the fields below for completeness and accuracy prior to submitting.
Welcome Back, ().
Has your work information changed?
We recently released version 3 of React Boilerplate1, one of the most popular React starter kits, after several months of work. The team spoke with hundreds of developers about how they build and scale their web applications, and I want to share some things we learned along the way.
We realized early on in the process that we didn’t want it to be “just another boilerplate.” We wanted to give developers who were starting a company or building a product the best foundation to start from and to scale.
Traditionally, scaling was mostly relevant for server-side systems. As more and more users would use your application, you needed to make sure that you could add more servers to your cluster, that your database could be split across multiple servers, and so on.
Nowadays, due to rich web applications, scaling has become an important topic on the front end, too! The front end of a complex app needs to be able to handle a large number of users, developers and parts. These three categories of scaling (users, developers and parts) need to be accounted for; otherwise, there will be problems down the line.
The first big improvement in clarity for big applications is the differentiation between stateful (“containers”) and stateless (“components”) components. Containers manage data or are connected to the state and generally don’t have styling associated with them. On the other hand, components have styling associated with them and aren’t responsible for any data or state management. I found this confusing at first. Basically, containers are responsible for how things work, and components are responsible for how things look.
Splitting our components like this enables us to cleanly separate reusable components and intermediary layers of data management. As a result, you can confidently go in and edit your components without worrying about your data structures getting messed up, and you can edit your containers without worrying about the styling getting messed up. Reasoning through and working with your application become much easier that way, the clarity being greatly improved!
Traditionally, developers structured their React applications by type. This means they had folders like actions/, components/, containers/, etc.
Imagine a navigation bar container named NavBar. It would have some state associated with it and a toggleNav action that opens and closes it. This is how the files would be structured when grouped by type:
react-app-by-type ├── css ├── actions │ └── NavBarActions.js ├── containers │ └── NavBar.jsx ├── constants │ └── NavBarConstants.js ├── components │ └── App.jsx └── reducers └── NavBarReducer.jsWhile this works fine for examples, once you have hundreds or potentially thousands of components, development becomes very hard. To add a feature, you would have to search for the correct file in half a dozen different folders with thousands of files. This would quickly become tedious, and confidence in the code base would wane.
After a long discussion in our GitHub issues tracker and trying out a bunch of different structures, we believe we have found a much better solution:
Instead of grouping the files of your application by type, group them by feature! That is, put all files related to one feature (for example, the navigation bar) in the same folder.
Let’s look at what the folder structure would look like for our NavBar example:
react-app-by-feature ├── css ├── containers │ └── NavBar │ ├── NavBar.jsx │ ├── actions.js │ ├── constants.js │ └── reducer.js └── components └── App.jsxDevelopers working on this application would need to go into only a single folder to work on something. And they would need to create only a single folder to add a new feature. Renaming is easy with find and replace, and hundreds of developers could work on the same application at once without causing any conflicts!
When I first read about this way of writing React applications, I thought, “Why would I ever do that? The other way works absolutely fine!” I pride myself on keeping an open mind, though, so I tried it on a small project. I was smitten within 15 minutes. My confidence in the code base was immense, and, with the container-component split, working on it was a breeze.
It’s important to note that this doesn’t mean the redux actions and reducers can only be used in that component. They can (and should) be imported and used from other components!
Two questions popped into my head while working like this, though: “How do we handle styling?” and “How do we handle data-fetching?” Let me tackle these separately.
Apart from architectural decisions, working with CSS in a component-based architecture is hard due to two specific properties of the language itself: global names and inheritance.
Imagine this CSS somewhere in a large application:
.header { /* … */ } .title { background-color: yellow; }Immediately, you’ll recognize a problem: title is a very generic name. Another developer (or maybe even the same one some time later) might go in and write this code:
.footer { /* … */ } .title { border-color: blue; }This will create a naming conflict, and suddenly your title will have a blue border and a yellow background everywhere, and you’ll be digging into thousands of files to find the one declaration that has messed everything up!
Thankfully, a few smart developers have come up with a solution to this problem, which they’ve named CSS Modules4. The key to their approach is to co-locate the styles of a component in their folder:
react-app-with-css-modules ├── containers └── components └── Button ├── Button.jsx └── styles.cssThe CSS looks exactly the same, except that we don’t have to worry about specific naming conventions, and we can give our code quite generic names:
.button { /* … */ }We then require (or import) these CSS files into our component and assign our JSX tag a className of styles.button:
/* Button.jsx */ var styles = require('./styles.css'); <div className={styles.button}></div> If you now look into the DOM in the browser, you’ll see <div></div>! CSS Modules takes care of “uniquifying” our class names by prepending the application’s name and postpending a short hash of the contents of the class. This means that the chance of overlapping classes is almost nil, and if they overlap, they will have the same contents anyway (because the hash — that is, the contents — has to be the same).
In CSS, certain properties inherit across nodes. For example, if the parent node has a line-height set and the child doesn’t have anything specified, it will automatically have the same line-height applied as the parent.
In a component-based architecture, that’s not what we want. Imagine a Header component and a Footer component with these styles:
.header { line-height: 1.5em; /* … */ } .footer { line-height: 1; /* … */ }Let’s say we render a Button inside these two components, and suddenly our buttons look different in the header and footer of our page! This is true not only for line-height: About a dozen CSS properties will inherit, and tracking down and getting rid of those bugs in your application would be very hard.
In the front-end world, using a reset style sheet to normalize styles across browsers is quite common. Popular options include Reset CSS, Normalize.css and sanitize.css! What if we took that concept and had a reset for every component?
This is called an auto-reset, and it exists as a plugin for PostCSS5! If you add PostCSS Auto Reset6 to your PostCSS plugins, it’ll do this exactly: wrap a local reset around each component, setting all inheritable properties to their default values to override the inheritances.
The second problem associated with this architecture is data-fetching. Co-locating your actions to your components makes sense for most actions, but data-fetching is inherently a global action that’s not tied to a single component!
Most developers at the moment use Redux Thunk7 to handle data-fetching with Redux. A typical thunked action would look something like this:
/* actions.js */ function fetchData() { return function thunk(dispatch) { // Load something asynchronously. fetch('https://someurl.com/somendpoint', function callback(data) { // Add the data to the store. dispatch(dataLoaded(data)); }); } }This is a brilliant way to allow data-fetching from the actions, but it has two pain points: Testing those functions is very hard, and, conceptually, having data-fetching in the actions doesn’t quite seem right.
A big benefit of Redux is the pure action creators, which are easily testable. When returning a thunk from an action, suddenly you have to double-call the action, mock the dispatch function, etc.
Recently, a new approach has taken the React world by storm: redux-saga8. redux-saga utilizes Esnext generator functions to make asynchronous code look synchronous, and it makes those asynchronous flows very easy to test. The mental model behind sagas is that they are like a separate thread in your application that handles all asynchronous things, without bothering the rest of the application!
Let me illustrate with an example:
/* sagas.js */ import { call, take, put } from 'redux-saga/effects'; // The asterisk behind the function keyword tells us that this is a generator. function* fetchData() { // The yield keyword means that we'll wait until the (asynchronous) function // after it completes. // In this case, we wait until the FETCH_DATA action happens. yield take(FETCH_DATA); // We then fetch the data from the server, again waiting for it with yield // before continuing. var data = yield call(fetch, 'https://someurl.com/someendpoint'); // When the data has finished loading, we dispatch the dataLoaded action. put(dataLoaded(data)); }Don’t be scared by the strange-looking code: This is a brilliant way to handle asynchronous flows!
The source code above almost reads like a novel, avoids callback hell and, on top of that, is easy to test. Now, you might ask yourself, why is it easy to test? The reason has to do with our ability to test for the “effects” that redux-saga exports without needing them to complete.
These effects that we import at the top of the file are handlers that enable us to easily interact with our redux code:
put() dispatches an action from our saga.take() pauses our saga until an action happens in our app.select() gets a part of the redux state (kind of like mapStateToProps).call() calls the function passed as the first argument with the remaining arguments.Why are these effects useful? Let’s see what the test for our example would look like:
/* sagas.test.js */ var sagaGenerator = fetchData(); describe('fetchData saga', function() { // Test that our saga starts when an action is dispatched, // without having to simulate that the dispatch actually happened! it('should wait for the FETCH_DATA action', function() { expect(sagaGenerator.next()).to.equal(take(FETCH_DATA)); }); // Test that our saga calls fetch with a specific URL, // without having to mock fetch or use the API or be connected to a network! it('should fetch the data from the server', function() { expect(sagaGenerator.next()).to.equal(call(fetch, 'https://someurl.com/someendpoint')); }); // Test that our saga dispatches an action, // without having to have the main application running! it('should dispatch the dataLoaded action when the data has loaded', function() { expect(sagaGenerator.next()).to.equal(put(dataLoaded())); }); });Esnext generators don’t go past the yield keyword until generator.next() is called, at which point they run the function, until they encounter the next yield keyword! By using the redux-saga effects, we can thus easily test asynchronous things without needing to mock anything and without relying on the network for our tests.
By the way, we co-locate the test files to the files we are testing, too. Why should they be in a separate folder? That way, all of the files associated with a component are truly in the same folder, even when we’re testing things!
If you think this is where the benefits of redux-saga end, you’d be mistaken! In fact, making data-fetching easy, beautiful and testable might be its smallest benefits!
Our components are now decoupled. They don’t care about any other styling or logic; they are concerned solely with their own business — well, almost.
Imagine a Clock and a Timer component. When a button on the clock is pressed, we want to start the timer; and when the stop button on the timer is pressed, you want to show the time on the clock.
Conventionally, you might have done something like this:
/* Clock.jsx */ import { startTimer } from '../Timer/actions'; class Clock extends React.Component { render() { return ( /* … */ <button onClick={this.props.dispatch(startTimer())} /> /* … */ ); } }/* Timer.jsx */ import { showTime } from '../Clock/actions'; class Timer extends React.Component { render() { return ( /* … */ <button onClick={this.props.dispatch(showTime(currentTime))} /> /* … */ ); } }Suddenly, you cannot use those components separately, and reusing them becomes almost impossible!
Instead, we can use redux-saga as the “mortar” between these decoupled components, so to speak. By listening for certain actions, we can react (pun intended) in different ways, depending on the application, which means that our components are now truly reusable.
Let’s fix our components first:
/* Clock.jsx */ import { startButtonClicked } from '../Clock/actions'; class Clock extends React.Component { /* … */ <button onClick={this.props.dispatch(startButtonClicked())} /> /* … */ }/* Timer.jsx */ import { stopButtonClicked } from '../Timer/actions'; class Timer extends React.Component { /* … */ <button onClick={this.props.dispatch(stopButtonClicked(currentTime))} /> /* … */ }Notice how each component is concerned only with itself and imports only its own actions!
Now, let’s use a saga to tie those two decoupled components back together:
/* sagas.js */ import { call, take, put, select } from 'redux-saga/effects'; import { showTime } from '../Clock/actions'; import { START_BUTTON_CLICKED } from '../Clock/constants'; import { startTimer } from '../Timer/actions'; import { STOP_BUTTON_CLICKED } from '../Timer/constants'; function* clockAndTimer() { // Wait for the startButtonClicked action of the Clock // to be dispatched. yield take(START_BUTTON_CLICKED); // When that happens, start the timer. put(startTimer()); // Then, wait for the stopButtonClick action of the Timer // to be dispatched. yield take(STOP_BUTTON_CLICKED); // Get the current time of the timer from the global state. var currentTime = select(function (state) { return state.timer.currentTime }); // And show the time on the clock. put(showTime(currentTime)); }Beautiful.
Here are the key takeaways for you to remember:
(il, vf, al)
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
↑ Back to topTweet itShare on Facebook
Inspiration isn’t tied to a specific timeframe or shows up when you need it. There isn’t a magic formula to rely on. Luckily, this year’s summer vacation was fruitful in providing us with many visual stimuli to get the creative process going. Enjoy!
This editorial illustration for the Hollywood Reporter has a really nice style. The face expressions are so well done with just a few simple lines. That’s not easy to accomplish!
A fantastic series to get the travel bug. Just by looking at this you’ve probably already guessed that the ‘A’ in this case stands for ‘Amsterdam’. Lovely usage of two complimentary colors cleverly applied, especially to add depth into shadows and highlights.
4Second installment of the travel bug illustrations I’ll be sure to follow. The letter ‘B’ stands for ‘BarcelonaÄ. Again, look at how depth is created by using a strong color palette and this beautiful clean 2D style. The famous parts of this city are so well done with such simple lines.
7James Curran is one of the masters of animated gifs to watch. This one made laugh and is so colorfully pleasant. And look at that jump! Just perfect.
Great integration of the colors used by Slack11. It shows how crazy work life is. Beautiful illustration style. Just perfect branding material.
12Illustration based on original stamps from Bulgaria. Quite beautiful! I love the bright yellow in combination with the darker color, as well as the red and orange tones.
15I first noticed the interesting structure/texture that works so well with the chosen colors. Love the circles, and ‘straight’ 90° lines — very geometrical. Feels a bit like a puzzle.
18The colors just pop so magnificently off the screen in this surf-related illustration. Very fitting for the subject. Inspiration came from late 80s and 90s surf artwork.
21Lovely illustration of the Duomo in Florence. Color palette is on point. Tasty texture, too. Simply beautiful to look at and get inspired.
24Well taken shot of one of my favorite moments in the month of May. The smell is just overwhelming of these beautiful bluebells. Magical light and bokeh.
27Some clever use of white space. The dog is just so awesomely done.
30Love the eyes and the illusion of the hair in the wind. Same with the dog ears, so cute. That lovely summer feeling on the bike! Perfectly expressed.
33An illustration which takes on curiosity and exploration of different tastes and flavors. It’s a great composition and an inspiring color palette.
36Great color scheme! Illustration that documents a trip to Italy to see Cinque Terre. It’s a must-see apparently. The geometry combined with how the colors are applied is just so perfect.
39An illustration for The Telegraph‘s property section on buying a home with protected trees in vicinity. Some inspiring choices of shapes and lines.
42If you like interesting collages, you’ll love the work of Jimmy Turell. The colors and the half-tone effects are the items that made me pick this one.
45Created for Wired48. Another color combo that works wonderfully well together. I always look at how things are constructed, and I’m quite impressed by this illustration.
49Beautiful colors of the sky — almost like fire.
52Wonderful die cut beer label design. I always admire such great lettering work. Be sure to check the rest of Ben Didier’s the portfolio55 as there is some stellar lettering work in there.
56The third installment in the Wanderlust alphabet that Jack Daly is creating. This time I believe the ‘C’ stands for ‘Copenhagen’. Interesting palette of colors in this one.
59Nice logo for the No-Li Brewhouse’s Small Batch Festival. The different styles of typefaces really work well together. Beautiful and elegant!
62The cover illustration for the spring edition of SHOP magazine in Austria. It depicts the Museum quarter of Vienna. Lovely combination of geometrical and elegant organic lines. Such perfect soft color tones combined with a few more brighter accents.
65Such a wonderful scene! Especially the colors used and the inspiring details such as the skirt of the woman and the boots of the guy sitting on the bench on the right.
68The fourth installment in the Wanderlust alphabet that Jack Daly is creating. This time the ‘D’ stands for ‘Dublin’. Just look at how shadows and highlights are applied — such perfect contrast.
71Well worth a two-hour round-trip hike I would say if you get to see a scenery like this. This place has a beautiful view of Ninachanca, Jirishanca, and Jirishanca Chico. Pure wanderlust!
74Not just because there’s a bicycle in it 😉 Most of all picked because it has a wonderful composition with fine details.
77A wonderful fusion between contemporary and retro. Some inspiring texture work going on in there as well. The wooden floor and the little details on the faces — look at those eyes!
80Part of a set of illustrations created for Facebook’s event cover images. Totally loving these colors! Lovely simplistic style, too.
83A great example of what is possible with a few pencil strokes. The socks on the girl are adorable.
86An illustration to get the travel bug going. Great style and subtle usage of textures. For a touristic guide of the Garda Lake.
89“Let the waves hit your feet and the sand be your seat!” Exactly. I love compositions where there is much to discover. Great mix of colors.
92Love how the diagonal line adds to the whole composition. Subtle use of shadows and transparency. Such perfect curved lines, especially hair and hat are done so perfectly in every way. Looking at this makes me want to go outside and ride.
95The fifth installment in the Wanderlust alphabet that Jack Daly is creating. This time the ‘E’ stands for ‘Edinburgh’. The color treatment is great again. So many good details.
98Super clean and the character really gets your attention. Love how the stockings are done. So simple, yet so elegant.
101Illustrating the never-ending cycle. I always love to analyze the many elements that make a fantastic illustration. You can learn a lot from it.
104One of the hardest things to get right is shooting directly into sunlight. This one nails it beautifully. Summer vibes!
107Adorable cuteness and great usage of some basic shapes. Look at that cute mustache of the guy on the left. The color palette is absolutely perfect.
110Getting out on your bicycle and discovering new roads and amazing sceneries is a joy hard to describe in words. Lovely light in this photo.
113Inspiring arrangement of all the different items in this composition. Beautiful 2D style with lovely subtle textures and patterns to finish things off. The colors also draw you in.
116Love the combination of line art and typography. Looks so elegant! The bike is so well drawn. It shines! Look at the frame, the handlebars and the saddle.
119The Brickmasters in the Shadows. Great editorial illustration. The duplication of the gentleman withthe hat is the eye-catcher. The chosen colors make the whole scene complete.
122Right on target! Love what is done with the lines here.
125Pretty fly! It looks highly complicated but is quite simplistic at the same time. The color scheming is on point, too. The subtle background gradient is so perfect.
128This looks fantastic! The many layers of typography are so inspiring.
131Lovely muted color palette for starters and some subtle textures work in combination with double shading makes this interesting. I really love the imagination and fantasy.
134Created for an editorial piece about geoengineering. Love how it all has been translated to the screen.
137In my opinion, a bit of humor always adds something special to any illustration. This one is about the Bicycle Adventure Meeting, a place where lonely, adventurous bike travelers join together. The lovely bright colors give this illustration a happy feeling.
140Well captured! The tranquility of the water is what does it for me. Just the right shutter speed I’m assuming to get the effect.
143Charming textured style and an inspiring color palette.
146Editorial illustration for an article on the importance of teamwork when learning road biking. I like how the three guys are nicely aligned and how the legs are drawn. As an illustrator, you have the freedom to break with reality in order to achieve beautiful compositions.
149(yk, il)
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
↑ Back to topTweet itShare on Facebook
SGS (formerly Société Générale de Surveillance) is a global service organization and provider of inspection, verification, testing and certification services across 14 industries. SGS’ website (along with 60 localized websites) primarily promotes the organization’s core services, as well as provides access to a multitude of useful services, supplementary content and tools. Our goal was to transform sgs.com1 from being desktop-only to being responsive.
This presented a unique set of challenges, especially around the legacy navigation system, which in areas was up to seven levels deep (divided into two parts) and which consisted of some 12,000 individual navigable items.
Our natural reaction upon seeing and using SGS’ navigation system for the first time was that surely the information architecture (IA) had to be simplified because of the sheer volume of navigable links and content. However, considering the navigation had already been optimized for search engines and the IA prior to this project and considering that SGS offers a wide selection of services across many industries (reflected in the volume of content), it was evident that refactoring the IA would not be a part of the solution.
Simply put, the navigation tree’s structure had to remain intact. Even so, that didn’t prevent us from making some minor adjustments to the IA. For instance, “News, Media & Resources” and “SGS Offices & Labs” were moved to the top level, for greater visibility. With the former, it was important to more clearly reflect that SGS regularly publishes news and hosts events. With the latter, it was vital that it, along with the contact page, were easily reachable from anywhere in the website’s structure. Therefore, the key question was how could such a behemoth of a navigation system be made to easily transition between different viewports while still being usable?
A healthy client-designer relationship4 is essential to the success of every project. Setting clear expectations as well as providing effective guidance ensures not only that key stakeholders remain focused throughout, but also that trust develops between all parties as the project progresses. This was definitely the case with this project; the collaboration between all parties and the mutual appreciation of each other’s roles and expertise were truly remarkable.
However, to ensure that all parties remained focused, we established at the kick-off meeting a number of important guidelines and requirements within which we could also exercise creativity (some of which we insisted on, others insisted on by the client):
With key guidelines established and knowing the navigation’s redesign wouldn’t require a significant overhaul of the IA, we subdivided the redesign into three key yet interdependent sets of activities:
Navigation is a fundamental element of page layout, regardless of the size or complexity of the website. While an off-screen pattern might seem appealing when you’re dealing with such a large-scale navigation system, remember that there can be issues5 when the navigation is not visible to the user.
SGS’ design team had initially tested a variety of concepts, because they had to not just evaluate the navigation interaction, but also create the right balance with the rest of the page and avoid clutter.
6Given the complexity of the website, it was vital that the navigation always remain visible and inform the user where they are within the tree structure. Rather than divide the navigation into two parts in the UI, we wanted the new navigation system to be seamless (from the top level right through to the bottom levels). Therefore, it had to enable the user to easily browse up and down the navigation tree, as well as sideways across the main sections.
To test and validate all of these combinations, we developed a prototype for each of the eight initial navigation concepts. The prototypes confirmed what the in-house team already suspected: The most viable option in terms of usability, maintenance, cross-screen experience, visual clutter and appeal was for the navigation to be placed in the sidebar on large screens and to appear as a dropdown menu on small screens. Essentially, the navigation module would be functionally and visually self-contained, regardless of screen size.
8While we will focus on specific interaction decisions in a minute, it’s worth pointing out that interactive prototypes don’t necessarily have to be discarded once a prototyped concept has been tested and validated.
We always develop prototypes directly in HTML, CSS and JavaScript using semantic, accessible and robust markup, because we are then often able to reuse the initial prototypes later in the design process. This meant that our initial prototype for the new navigation system became the cornerstone for the eventual full website prototype, which included all of the page templates and modules.
In delivering the full prototype, we also ensured the style guide was generated automatically for the SGS team. By getting SGS’ design team to think in terms of designing and developing modules, rather than complete pages, the generated style guide would require little ongoing maintenance. The style guide itself refers to all of the distinctive modules used, with each module containing a precise description, code example and automatically generated link to the page template where it is used. Our technology of choice for automating tasks and features is PHP, but automation can be achieved using any server-side language, as long as the output is semantic HTML. (We developed a specific file-system framework for our prototypes, but that’s a topic for another occasion.) Later on in this article, we will explain how server-side scripting helped us to maintain and test multiple versions of the navigation.
Even though starting with semantic, accessible and robust HTML is vital, the principle of “content-first, navigation-second” is just as important because it helps you to account for any possible future exceptions. There was one exception to the “content-first, navigation-second” rule in this project: the home page. We discovered, based on analytics, that the navigation was viewed as the most important element on the home page, which meant it had to come before any core content on the page.
Once the decision was made to design and develop a self-contained, screen-size-agnostic navigation module, it was time to focus on navigation interactions. Considering that we had adopted a mobile-first approach to designing the navigation, the navigation module itself not only would naturally function as expected in small viewports, but would easily scale to work in large viewports, too.
Due to the size of the navigation and the potential number of nested levels, we had to eliminate some of the more common mobile navigation patterns10 as options — for instance, select dropdowns and the priority+ pattern. We focused on prototyping three interactive versions of the navigation: a slider, an accordion, and an accordion and slider. Each has its pros and cons, which naturally influenced our decision.
Accordion
The accordion is probably the most common pattern on mobile. It discloses progressively, revealing more detailed information as the user progresses through the topic or action. It also ensures the user does not get overwhelmed, which is why we wanted to use it as a baseline solution.
Here are the accordion’s pros:
:target pseudo-class11.And the accordion’s cons:
Slider
This was initially our favorite solution, but it misses one important element: allowing truly sideways browsing across the main sections. It wouldn’t be such a problem if the user always starts browsing from the home page, because they would become increasingly familiar with the main sections. However, for users who land on a page deep in the navigation tree, it definitely would have been a usability problem. For instance, users who land on the third, fourth or fifth level would have to traverse up the tree in order to reach the contact page. Traversing seven levels is no fun, no matter how motivated the user might be.
Slider pros:
Slider cons:
Hybrid (accordion and slider)
We really wanted to maintain the attractiveness of the slider, while still allowing sideways browsing. Therefore, we developed of a hybrid solution combining the best elements of the two navigation patterns. Incidentally, it was also the solution we settled on.
12Hybrid pros:
Hybrid cons:
As mentioned, the user should be able to browse up and down the navigation tree, always aware of where they have come from and where the navigation will take them next. However, that’s just the baseline interaction — we had to address quite a few additional issues in order to develop a usable navigation system.
Apart from current and ancestor navigation items being distinct in design (which is now, thankfully, a well-established practice), we further improved the navigation and general usability by helping the user to understand where they are and what they’re exploring. Helping the user to understand the current page and its parents, as well as any relevant children relationships, was far from enough. Other important actions were required:
Note: We used breadcrumbs to ensure that the current page position is always clear to the user. Because we wanted to avoid skipping levels altogether, the information in the breadcrumbs and the navigation had to match one to one, even with pseudo-levels (i.e. levels that don’t have an actual page).
The user requirements above resulted in five types of semantically different navigation items, with additional helper links that would allow the user to traverse up and down the tree without having to leave the current page. You can imagine the complexity and interdependencies that come with so many moving parts.
14All elements in the navigation are animated using CSS, with each animation having two distinct parts:
First, the different tree levels in the slider are toggled by changing the class of the master wrapper. For example, the closed navigation wrapper has a class of .depth-0. When a top-level item is expanded, the class changes to .depth-1. When a second-level item from within that top-level item is selected, the class changes to .depth-2, and so on. This results in a fairly simple set of CSS rules that get applied to a single element — the topmost-ordered list in a slider:
.depth-1 .l-0.nav-open > ol { left: 0; } .depth-2 .l-0.nav-open > ol { left: -100%; } .depth-3 .l-0.nav-open > ol { left: -200%; } In the example above, .l-0 corresponds to a zero-level list item, and .nav-open is toggled whenever the accordion is set to open. This means that the ordered list of a direct child in an open accordion list item is absolutely offset to the negative-left position.
Secondly, considering that each level contains a variable number of list items, the transition between any two adjacent levels has to be smooth.
16To achieve this, we made sure there is always sufficient vertical room for the horizontal animation to run smoothly. The height is calculated and applied on the fly by retrieving the vertical offset of the element about to enter the screen. This means we had to account for a total of four possible scenarios, but really only needed to resolve two, each with a slightly different order of execution:
Both animations are initiated at the same time, but the second animation gets initiated after a 300-millisecond delay, which is exactly the duration of the first animation (specified in CSS using the transition-duration property). The reason for this is suboptimal animation performance on less-capable devices when multiple layers overlap before disappearing “behind the curtain.” The simplified code looks like this:
if (newHeight < oldHeight) { heightTimeout = 300; } else { heightTimeout = 0; } setTimeout(function() { $('.l-0.nav-open').css('height', newHeight); }, heightTimeout); Already faced with a complex set of interdependencies, we realized upon testing the navigation that there was room for improvement.
First, because web fonts sometimes load a little later than the rest of the page, some strings of text in the navigation that are meant to be on one line would expand to a second line before the web font had fully loaded. For instance, the top-level section link “News, Media and Resources” falls onto two rows when rendered in the fallback font.
17Because everything had to be really compact (since we had to use absolute positioning for the sliding animation), the only solution was to reset the height of the affected element after the web font had loaded. This was done using Web Font Loader19, developed by Bram Stein20 for Adobe Typekit21 and Google Fonts22.
WebFont.load({ custom: { families: ['FONT_NAME_1', 'FONT_NAME_2'] }, active: function() { // recalculate things here }, timeout: 5000 }); Note: Did you notice how we used a 5-second timeout? In our testing, we found this to be the sweet spot that made it work on our baseline “good 2G” (450 KB per second) connection!
Secondly, because we decided to conditionally load the navigation nodes in order to improve initial loading performance (more on that in the next section), we wanted the user to be kept aware of how many navigation items are available, in case there is a delay in loading a branch of the navigation tree. We did this by repeating a placeholder background image that resembles a string of text23.
24Finally, we appended the placeholder code in the DOM with JavaScript before requesting the navigation branch. This keeps the DOM as clean as possible.
element.append('<ol><li></li></ol>'); $.get('NAVIGATION_BRANCH_URL', function(data){ // replace the loader with the branch element.find('ol').replaceWith(data); }); If you recall, one of our key targets in the project was for the website to perform at least 20% better than competitors’ websites. Not only did we achieve this target, but in doing so we helped SGS to significantly reduce overall page weight and loading times. Take a look at the following before-and-after statistics:
| HTTP requests | File size: total | File size: HTML | |
|---|---|---|---|
| Original SGS home page | 40 | 1,500 KB | 72 KB |
| Original SGS industry page | 60 | 2,200 KB | 50 KB |
| New responsive home page | 17 | 960 KB | 42 KB |
| New responsive industry page | 20 | 680 KB | 40 KB |
That’s correct! When we rendered the full navigation tree for the first time in our prototype, it amounted to 3 MB of bare HTML. No header, no footer and no content — just the navigation tree consisting of 12,000 individual links.
Prior to the redesign, every page contained the core navigation tree, and each industry page also included an industry-specific navigation tree, implemented as a separate module. However, the desktop-optimized design made the core or industry-specific navigation not only difficult to use on small viewports, but difficult to maintain, too. That’s why one of the key goals of the redesign was to consolidate the tree into a single and easy-to-maintain module.
To thoroughly test each of the three interactive versions of the navigation, as well as evaluate their performance, a flexible testing environment was essential. This would enable us to make changes quickly, as well as to maintain concurrent versions so that we could easily compare them against each other.
Considering the size of the complete navigation tree (up to seven levels deep and 12,000 navigable links), being able to test parts of the navigation tree as well as the full tree itself was important. SGS’ in-house developers were able to export the full navigation tree as a CSV file from their content management system, which allowed us to create an easily configurable PHP function to output either the full tree or part of it, depending on what we needed to test.
Our PHP function also simplified the HTML maintenance of the navigation tree’s structure, because the aforementioned link markup and class names could be easily changed in a single place. Using a server-side language to avoid having to repeat code might sound obvious, but creating this type of environment was not just a welcome addition, but was actually mission critical, because it was the prerequisite to agile experimentation and testing.
We mentioned that we had to conditionally load the navigation nodes to improve initial loading performance. The question that then needed answering was, How much of the navigation tree should be loaded initially and how much should be loaded later, and when? After testing and comparing the weights and sizes of the different navigation tree branches, as well as studying user behavior on the existing live website, a few interesting conclusions emerged.
First, visitors who were interested in only one type of industry rarely visited other industries. Once browsing their selected industry category, each visitor would typically go on to explore just a couple of other pages.
Secondly (and as we had initially thought), the industry-specific branches caused the majority of performance overhead. When we removed the industry branches altogether, the HTML was reduced to 70 KB, which is a lot better than 3 MB! Still, it meant that each of the 14 industry branches weighed between 300 and 500 KB. When we fragmented each service branch further, we found that each subsequent level would weigh around 24 KB on average.
While we were aware that the HTML could be further reduced by optimizing the class names and adding DOM nodes via JavaScript (more on that in a minute), we still had to determine whether it was best to initiate a single HTTP request at around 300 to 500 KB or to initiate an HTTP request of around 24 KB at each level. Initially, it seemed that sending a 24 KB request each time the user progressed further down the navigation tree would be more beneficial. However, this would have resulted in multiple HTTP requests being sent over the network, which was far from ideal, considering that network latency is often one of the biggest bottlenecks for website performance. It also didn’t make sense to predict the loading of any industry branches either, except when the user showed intent by hovering over an industry link.
Due to the complexity of the navigation and the quantity of links, the following arrangement offered by far the best compromise:
mouseover event.The logic for deeper pages was somewhat different, because the navigation needs to be accessible without JavaScript enabled. Therefore, if a user (or even a search engine bot) lands on a deep page, the following would happen:
If you truly want to optimize your HTML, all non-essential items have to be offloaded to CSS and JavaScript. We rigorously pruned everything except the ordered list, its list items and their respective links. All non-essential links (i.e. navigation aids) were also removed from the HTML and are reinserted back in the DOM using JavaScript (because they are ineffective without JavaScript anyway). These non-essential links enable the user to do a couple of things:
While the resulting DOM was still immense, the navigation aids no longer needed to be transferred individually over the network.
Finally, the last piece of optimization we undertook was to reduce the number of classes, as well as to shorten the length of class names; for example, .very-long-class-name became .v-l-c-n. While the latter yielded the biggest gains, such optimization is difficult to justify because it usually doesn’t significantly trim the size of the HTML file, and, more importantly, it reduces the clarity of the code, thus possibly making maintenance more difficult. However, shaving off even a single byte from each of the 12,000 list items made it a worthwhile exercise and an acceptable trade-off.
The result? A whooping 40 KB or so of initial HTML (8 to 9 KB when compressed and transferred over the network), and 200 to 300 KB of HTML for each industry (15 to 25 KB when compressed and transferred).
We like to use an analogy from the sports world: Improving every tiny thing by 1% dramatically improves performance26. This applies to what we did in the SGS project and its intricate navigation. By focusing on the finer details, improving each detail by a tiny bit, we significantly reduced the complexity of the navigation and improved loading times, while keeping the navigation appealing and engaging for users. What could have been a nightmare and a tough nut to crack turned into a technically and interactively relevant solution, flexible enough to accommodate further improvement.
Most of all, the design process of continually prototyping, investigating options and refining the best solutions proved to be extremely effective — so much so that it has provided a strong case for the in-house team to apply the same fundamental principles when developing other products in the organization, not to mention that it will help the team to continue refining and optimizing the new navigation system. No web project is ever truly complete; there are always a few more things on the to-do list. That’s perfectly fine, as long as we keep on testing, refining and providing the best experience for users.
(vf, il, yk, al)
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
↑ Back to topTweet itShare on Facebook
The common wisdom for most companies that set out to build an app is to build a native Android or iOS app, as well as a supporting website. Although there are some good reasons for that, not enough people know about the major advantages of web apps. Web apps can replace all of the functions of native apps and websites at once. They are coming more and more to the fore these days, but still not enough people are familiar with them or adopting them.
Here, you will be able to find some do’s and dont’s on how to make a progressive web app, as well as resources for further research. I’ll also go into the various components and support issues surrounding web apps. Although not every browser is friendly to them, there are still some compelling reasons to learn more about this technology.
A progressive web app is an umbrella term for certain technologies that go together to produce an app-like experience on the web. For simplicity’s sake, I’ll refer to them simply as web apps from now on.
An ideal web app is a web page that has the best aspects of both the web and native apps. It should be fast and quick to interact with, fit the device’s viewport, remain usable offline and be able to have an icon on the home screen.
At the same time, it must not sacrifice the things that make the web great, such as the ability to link deep into the app and to use URLs to enable sharing of content. Like the web, it should work well across platforms and not focus solely on mobile. It should behave just as well on a desktop computer as in other form factors, lest we risk having another era of unresponsive m.example.com websites.
Progressive web apps are not new. Mobile browsers have had the ability to bookmark a website to your phone’s home screen since 2011 (2013 on Chrome Android), with meta tags in the head determining the appearance of the installed web page. The Financial Times has been using a web app4 for digital content delivery on mobile devices since 2012.
Moving to a web app enabled the Financial Times to use the same app to ship across platforms in a single distribution channel. Back when I was working for the Financial Times, with a single build we were able to support the following:
That truly achieves “build once, deploy anywhere.”
There are some good reasons why supplementing a native app with a website is still standard practice for most major companies. Among them are concerns about browser support and the fact that most users are acclimated to using native apps. I will address these issues in more detail later. Not least of these concerns is how the app will get exposure if it is not in an app store.
I would argue that being in an app store has no major advantage because it has been shown that if you are not in the top 0.1% of apps in the app store, you are not getting significant benefit from being there.
Users tend to find your apps by first finding your website. If your website is a web app, then they are already at their destination.
One of the strengths of a web app is that it enables you to improve engagement by reducing the number of clicks required to re-engage the user between landing on your website and engaging with your app.
By having the user “install” your web app by adding it to their home screen, they can continue engaging with your website. When they close down the web browser, the phone will show them where the web app is installed, bringing you back to their awareness.
Modern web apps are based on a new technology called service workers. Service workers are programmable proxies that sit between the user’s tab and the wider Internet. They intercept and rewrite or fabricate network requests to allow very granular caching and offline support.
Since the origins of the web app in 2011, which enabled websites to be bookmarked to the home screen, a number of developments have taken place to lay more groundwork for the creation of progressive web apps.
Chrome 38 introduced the web app manifest, which is a JSON file that describes the configuration of your web app. This allowed us to remove the configuration from the head.
In Chrome 40 (December 2014), service workers started to roll out across Firefox and Chrome. Apple has so far chosen not to implement this feature in Safari as of the time of writing but has it “under consideration8.” The service worker’s function is to simplify the process of bringing an app offline; it also lays the foundation for future app-like features, such as push notifications and background sync.
Apps that were built based on the new service workers and the web app manifest became known as progressive web apps.
A progressive web app is not the same as the spec. In fact, it started out as a definition of what a web app should be in the era of service workers, given the new technology being built into browsers. Specifically, Chrome uses this definition to trigger an install prompt in the browser when a number of conditions are met. The conditions are that the web app:
display: "standalone");In this case, “progressive” means that the more features the browser supports, the more app-like the experience can be.
The prompt to install the web app is currently shown under varying conditions across Opera, Chrome and the Samsung browser.
Apple has indicated interest in progressive web apps for iOS, but at the time of writing it still relies on meta tags for web app configuration and the application cache (AppCache) for offline use.
We know what a website looks like and what an app looks like, but at what point does a website become a web app? There is no definitive metric as to what makes something a web app rather than a website.
Here we will go into some more detail about the characteristics of a web app.
Taking your website offline brings some major advantages.
First, it will still work when the user is on a flaky network connection.
In addition, the time from opening the app to using the app is greatly reduced if the app does not rely on the network. This gives the user a great experience. A carefully optimized web app can start faster than a native one if the browser has been used recently.
There are two methods to getting a website to work offline:
Service workers are like other web workers in that they run in a separate thread, but they are not tied to any specific tab. They are assigned a URL scope when they are created, and they can intercept and rewrite any requests in this scope. If your service worker sits at http://example.com/my-site/sw.js, it will be able to intercept any requests made to /my-site/ or lower but cannot be made to intercept requests to the root http://example.com/.
Because they are not tied to any tab, they can be brought to life in the background to handle push notifications or background sync. Not least, it is impossible to permanently break your website with them because they will automatically update when a new service worker script is detected.
A good guideline is that, if you are building a new website from scratch, start off with a service worker. However, if your website already works offline with AppCache, then you can use the tool sw-appcache-behavior11 to generate a service worker from this, because we may soon reach the point when some browsers will only accept service workers and some will only accept AppCache.
Because AppCache is being deprecated, I will not discuss it further in this article.
(Also, see “Setting Up a Service Worker12” for more detailed instructions.)
Because a service worker is a special type of shared web worker, it runs in a separate thread to your main page. This means that it is shared by all web pages on the same path as the service worker. For example, a service worker located at /my-page/sw.js would be able to affect /my-page/index.html and my-page/images/header.jpg, but not /index.html.
Service workers are able to intercept and rewrite or spoof all network requests made on the page, including those made to data:// URLs!
This power enables it to provide cached responses to get pages to work when there is no data connection. Still, it is flexible enough to allow for many possible use cases.
It is only allowed in secure contexts13 (i.e. HTTPS) because it is so powerful. This prevents third parties from permanently overriding your website using an injected service worker from an infected or malicious Wi-Fi access point.
Setting up HTTPS nowadays might seem daunting and expensive, but actually it has never been easier or cheaper. Let’s Encrypt14 provides free SSL certificates and scripts for you to automatically configure your server. In case you host on GitHub, GitHub Pages are automatically served over HTTPS. Tumblr pages can be configured to run on HTTPS, too. CloudFlare can proxy requests to upgrade to HTTPS.
Offlining usually involves picking certain caching methods for different parts of your website to allow them to be served faster or when there is no Internet connection. I will discuss various caching methods below.
I use Service Worker Toolbox2915 to abstract away complex caching logic. This library can be set to handle the routing by providing four preconfigured routes, which can be configured in a clean fashion. It can be imported into your service worker.
Precaching pulls down requests before your website works out that they are needed. This can greatly decrease first paint time because your website doesn’t need to parse /site.css before it starts downloading your website’s logo, /images/logo.png.
toolbox.precache(['/index.html', '/site.css', '/images/logo.png']); Allowing users to revisit your website when they are offline in the simplest case means falling back to the cache if the device is offline. Setting a timeout here is important because a flaky network, misconfigured router or captive portal could leave the user waiting indefinitely.
toolbox.router.default = toolbox.networkFirst; toolbox.options.networkTimeoutSeconds = 5; In reality, we can actually be a little smarter because the majority of your assets will not change over time. We probably just want to get the content as soon as possible, whether from the cache or the network. The following line tells Service Worker Toolbox that all requests to the images’ paths should come from the cache if they are available there.
toolbox.router.all('/images/*', toolbox.fastest); In this case, when the user is authenticating, it is important that we not just return a cached response; we should state that requests made to /auth/ should be network-only.
toolbox.router.post('/auth/*', toolbox.networkOnly); Here are some good practices for offlining:
toolbox.cacheOnly is used, then it could also save the user’s data.Note: The browser cache and the Cache API are different animals. The Cache API has been bypassed in the case of network-first or network-only. The request might still hit the browser’s cache because the caching headers in the request say it is still valid. This could result in the problem of the user receiving a mixture of cached and fresh data. Jake Archibald has some good suggestions for avoiding this issue16.
If you are in Chrome or Opera, go to chrome://serviceworker-internals. This will allow you to inspect and pause and uninstall your service worker script.
In recent versions of Chrome and Opera, you can get detailed views and debugging tools through the “Application” tab in the inspector.
17People have come to expect that the web does not have the smoothly animated interfaces that native apps do. However, the same standard is not acceptable for web apps. Web apps must animate smoothly, lest our users feel we are delivering a degraded, second-class experience. We have three goals to make it feel fast:
Off the bat, the most essential item is this, in the head of the document:
<meta name="viewport" content="width=device-width"> This line ensures that there is no 300-millisecond tap delay on phone browsers that are Chromium-based or Firefox, but it still allows the user to zoom in by pinching (great for accessibility).
Since iOS 8 came out, clicks are fast by default but might seem slow if the tap is fast, according to certain heuristics19. If this is an issue for you, I recommend using FastClick20 to remove the delay.
There is also the issue of animation performance. You’ll probably want a lot of pretty elements animating in and out, elements that can be dragged by the user, and other lovely interactions.
Web performance can be discussed in great detail and is a subject close to my heart, but I won’t go into much detail here. I will touch on what I do to ensure that my interactions and animations are crisp and smooth.
Dig around or ask around your friends or family for an old smartphone. I usually borrow my partner’s Nexus 4.
Plug the phone into your computer, and go to chrome://inspect/#devices. This will open an inspection window, which you can use to inspect the web pages running on the phone. You can use profiling and view the timeline to find sources of poor performance and then optimize them based on a real baseline device.
Animating certain CSS properties is one of the biggest causes of jittery animation, known as jank. CSS Triggers21 is a great resource for determining which properties can be safely animated without causing the browser to repaint or re-lay out the whole page.
If writing performant animations is a daunting task for you, many libraries out there will handle the job. A favorite of mine is GreenSock22, which can handle touch interactions very well, such as dragging items, and which can do very fancy animation and tweening.
Push notifications are a great way to re-engage with users. By prompting the user, you bring your app to the forefront of their mind. They could finish off an unfinished transaction or receive alerts about relevant new content.
Make sure your push notifications are relevant to the user for events happening at that moment. Don’t waste their time on things that can be done later. What you are notifying them about should require their action (replying to someone or going to an event). Also, don’t push a notification if your web app is visible or in focus.
When interacted with, a notification should take the user to a page that works offline. Notifications can hang around unread; they might be interacted with when the user has no network connection. The user will get frustrated if your push notification refuses to work after they have tried to interact with it.
The very best experience for push notifications frees the user from having to open your web app at all! “You have a new message” is useless and as annoying as a clickbait headline. Display the message and the sender.
Action buttons in the notification can provide interaction prompts that do not necessarily open the browser (“Like this post,” “Reply with yes,” “Reply with no,” “Remind me later”). These serve the user on their terms, keeps them engaged and minimizes their investment of time.
If you spam the user with regular or irrelevant notifications, they might disable notifications for your app in the browser. After that, it will be almost impossible to re-engage them, and you won’t be able to easily prompt them for permission again!
To avoid this, make the route to your app’s “disable notification” button clear and easy. Once you have addressed any issues frustrating users, you can try to re-engage.
The Push Notification API requires a service worker. Because it is possible to receive push notifications when no browser tab is open, the service worker will handle the notification request in a background thread. It can perform async operations, such as making a fetch request to your API before displaying the notification to the user.
To create a push notification, make a request to an endpoint provided by the browser manufacturer. For Chromium-based browsers (Opera, Samsung and Chrome), this would is Firebase Cloud Messaging. These browsers also behave a little off-spec as well.
One can find the details of this by requesting push-notification permission:
serviceWorkerRegistration .pushManager .subscribe({ // Required parameter as receiving updates // but not displaying a message is not supported everywhere. userVisibleOnly: true }) .then(function(subscription) { return sendSubscriptionToServer(subscription); }) The subscription is an object that looks like this:
{ "endpoint": "http://example.com/some/uuid" } In the example above, the uuid uniquely identifies the browser currently being used.
Note: Chromium-based browsers behave a little differently. You’ll need a Firebase app ID, which needs to be entered in your web app’s manifest file (for example, "gcm_sender_id": "90157766285").
Also, the endpoint will not work in the format it is given. Your server needs to mangle it slightly to get it to work23. It needs to be a POST request, with your API key in the head and the uuid in the body.
When sending a push notification, it is possible to send data in the body of the push notification itself. This is complex and involves encrypting the contents in the API request. The web-push24 package for Node.js can handle this, but I don’t prefer it.
It is possible to perform async requests once the notification has been received, so I prefer to send a minimal notification, known as a “tickle,” to the client, and then the service worker will make a fetch request to my API to pull any recent updates.
Note: The service worker can be closed by the browser at any point. The event.waitUntil function in the push event tells the service worker not to close until the event is finished.
self.addEventListener('push', function(event) { event.waitUntil( // Makes API request, returns Promise getMessageDetails() .then(function (details) { self.registration.showNotification( details.title, { body: details.message, icon: '/my-app-logo-192x192.png' }) }) ); }); You can listen for a click or press interaction on the notification events, too. Use these to decide how to respond. You could open a new browser tab, focus an existing tab or make an API request. You can also choose whether to close the notification or keep it open. Use this functionality with actions on the notification to build great functionality into the notification itself. This will make for a great experience, because the user will not be required to open your app each time.
The final and most important point is that, in our rush for an app-like experience, we should not forget to stay web-like in one very important aspect: URLs.
Installed web apps often hide the browser shell. There is no address bar for the user to share the current URL, and the user can’t save the current page for later.
URLs have a unique web advantage: You can get people to use your app by clicking, rather than by describing how to navigate it. All the same, it is very easy to forget to expose this to users. You could write the best app in the world, but if no one can share it, you will have done yourself a major disservice.
It comes down to this: Provide ways to share your app via either sharing buttons or a button to expose the URL.
Check out Is ServiceWorker ready?25 for the current status of support for service workers across browsers.
You may have noticed throughout all of this that I have mentioned Chrome, Firefox and Edge but left out Safari. Apple introduced web apps to the world and has shown interest in progressive web apps, but it still does not support service workers or the web app manifest. What can you do?
It is possible to make an offline website for Safari with AppCache, but doing so is both difficult and fraught with weird edge cases that can break the page or keep it permanently out of date after first load.
Instead, build a great web app experience. Your work will not have been wasted because the experience will still be great in Safari, which is a very good browser. When service workers do come to Safari, you will be ready to take advantage of them.
Finally, we can look forward to a lot of exciting developments in the world of web apps, with increasing support for the technologies behind them and new features coming to the web platform, such as the Web Bluetooth API for interacting with hardware, WebVR for virtual reality, and WebGL 2 for high-speed gaming. Now is a great time to explore the possibilities of web apps and to take part in shaping the future of the web.
(vf, yk, il, al)
Editor’s Note:We kindly thank Christian Heilmann32 for his kind technical and editorial support — this article wouldn’t be possible without him.
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
↑ Back to topTweet itShare on Facebook
How often do you have to explain the purpose of a study, objectives, goals or measurements within your company? Maybe you need to prepare a presentation or a brief overview of what next steps should be taken, or maybe you simply need to build a shiny, new pattern library?
Whatever project you may be working on, today’s icon sets will come in handy. All of the vector icons were tirelessly crafted by the design team at Ecommerce Website Design121, and come in various formats that can be used for personal as well as commercial purposes.
This exclusive icon pack is licensed under under a Creative Commons Attribution 3.0 Unported2 license. You may modify the size, color or shape of the icons. No attribution is required, however, reselling of bundles or individual pictograms is not cool. Please provide credits to the creators and link to the article in which this freebie was released if you would like to spread the word in blog posts or anywhere else.
This consistent and beautifully diverse icon set offers a retro discreet feel, fading hues of army green, yellow, orange, red and grey, mixing into sharply defined images.
5These e-commerce linear icons come in green, blue and red, displaying an array of signs, shops, clothes, even barcodes and currencies that clarify and lead the shopper. As you want to help, not to confuse your guests and potential clients, these icons are like Santa’s little helpers, taking some of the stress off your hands and wrapping big expectations into small, but mighty editable buttons.
7
9“The 45 Flat Line User Experience Icon Set came from a need for UX (User Experience) icons as opposed to the abundance of User Interface icon sets. The retro color scheme and shapes are an escape from the standard ones. The icons are created in 2px line/stroke design filled with colors and details in line style as shapes. The stroke/line are fully editable in the .eps and .ai file.
With online shopping galloping in retail stats like a purebred stallion towards the finish line at the Royal Ascot, no wonder that e-commerce is in high demand. Together with SEO and social media icons, e-commerce icons are some of the most requested sets. As they always come in handy, these 38 E-Commerce Linear Icons are ready to take their job seriously and show up in all the right places. The designer of the collection literally keeps all her ideas and inspiration for colors, designs, shapes, in a special folder. This system helps her quickly answer to the customer’s preferences. Although there are many free e-commerce icons out there, design-wise they aren’t too adventurous. It was the regular RGB colors that inspired the designer to create the color scheme. These are clean, elegant linear e-comm icons with a retro touch – in 2px stroke design on fresh color backgrounds. The stroke/line are fully editable in the .eps and .ai file.”
A big thank you to the team at Ecommerce Website Design121 — we sincerely appreciate your time and efforts. Keep up the brilliant work!
(il, vf)
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
↑ Back to topTweet itShare on Facebook
This week’s reading list consists of a lot of little, smart details that you can use on websites. From tweaking the user’s reading experience during page load to pure JavaScript functions and verifying the integrity of external assets. And finally, we see some articles on thinking differently about established working habits — be it working on AI without data or the virtue of not shipping a feature.
Please note that I’ll be on vacation for the next four weeks, so please don’t expect any new Web Development Reading List before October, 7th. Enjoy September, your work, your life!
X-Content-Type-Options: nosniff to the browsers.SameSite option to stop cross-site timing attacks12.
14font-size-adjust, or new techniques such as scroll anchoring, you can improve the situation enormously.And with that, I’ll close for this week. If you like what I write each week, please support me with a donation21 or share this resource with other people. You can learn more about the costs of the project here22. It’s available via email, RSS and online.
— Anselm
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
↑ Back to topTweet itShare on Facebook
Support for responsive images1 was added to WordPress core in version 4.4 to address the use case for viewport-based image selection2, where the browser requests the image size that best fits the layout for its particular viewport.
Images that are inserted within the text of a post automatically get the responsive treatment, while images that are handled by the theme or plugins — like featured images and image galleries — can be coded by developers using the new responsive image functions and filters. With a few additions, WordPress websites can accommodate another responsive image use case known as art direction3. Art direction gives us the ability to design with images whose crop or composition changes at certain breakpoints.
In this article, I’ll show you how to set up a WordPress website for art direction by going through three progressive examples:
In the art direction example, we’ll be adding some PHP, a polyfill and a cropping plugin to the website.
Support for responsive images is all about options: We provide a well-described array of image files to the browser, and the browser applies its knowledge of the width and pixel density of the viewport to request the file with the most appropriate resolution. The workhorse here is the srcset attribute, which can be used with img and source tags. Similar to, but more informative than, its older cousin, the src attribute, srcset is essentially a “set of sources” — that is, a list of image files available for downloading. For detailed background on the srcset attribute, I recommend Eric Portis’ article on responsive images7.
Since version 4.4, WordPress automatically adds a srcset attribute to any image that is run through the_content filter. In other words, when WordPress is creating the HTML for your web page, it scans the post or page’s text for img tags and adds a srcset attribute to any tags that don’t already contain one. You won’t see the srcset in the post editor (unless you explicitly add one, although you should generally let WordPress take care of it), but it will be present in the page’s HTML source.
To offer multiple image sizes in the srcset, WordPress leverages its standard behavior of automatically creating several smaller versions of your image files when you upload them to the “Media Library.” You can find these sizes listed on the “Media Settings” screen (under the “Settings” menu in the WordPress administration interface), along with their default values; not listed is the new “medium_large” image size8 (768 pixels wide, with no height limit), the size of which can be changed by a theme or plugin but not through the administration interface.
By default, the autogenerated “medium,” “medium_large” and “large” image sizes are soft-cropped — that is, they maintain the same aspect ratio as the original file. (I refer to these as “scaled” versions.) In these cases, the width given on the “Media Settings” screen is the constraining parameter. In contrast, the “thumbnail” size is hard-cropped to a 150 pixel square, so it most likely has a different aspect ratio than its bigger brothers. WordPress relies on aspect ratio to determine which image sizes should be included in a srcset, and we’ll be seeing this play out in each of our examples.
Let’s say that you upload a 1400 × 952-pixel image to the WordPress media library and keep the image sizes at their default values. Behind the scenes, WordPress creates the following versions of the original image:
| Size | Width (px) | Height (px) | Cropping | Aspect ratio (w/h) |
|---|---|---|---|---|
| full (original) | 1400 | 952 | soft | 1.47 |
| large | 1024 | 696 | soft | 1.47 |
| medium_large | 768 | 522 | soft | 1.47 |
| medium | 300 | 204 | soft | 1.47 |
| thumbnail | 150 | 150 | hard | 1 |
If you then insert the “large” (1024 pixels wide) version into a post and view the HTML source for the published web page, you’d see something like this:
<img src="sample-1024x696.jpg" width="1024" height="696" srcset="sample-300x204.jpg 300w, sample-768x522.jpg 768w, sample-1024x696.jpg 1024w" sizes="(max-width: 1024px) 100vw, 1024px" alt="A meaningful sample image"> WordPress has generated a srcset for us using the “medium,” “medium_large” and “large” sizes because these images all share the same aspect ratio. The “thumbnail” version wasn’t included, which makes sense because we want those images to look the same in every viewport.
Two other bits of information are also included in the HTML above. First, the w descriptors within the srcset tell the browser the actual pixel widths of the files; without these, the browser would need download the images to find out their dimensions. Secondly, WordPress’ default value for the sizes attribute tells the browser how wide the image is intended to be in this particular layout. Here, for viewports narrower than 1024 pixels, the image should fill and scale with the size of the viewport; otherwise, the image should be displayed at its default width of 1024 pixels and not any wider. With these final pieces to the puzzle, the browser can now make an intelligent image request, whether it be to display a high-resolution file on a “Retina” display or a low-resolution file on a small phone.
Now that we understand how WordPress leverages the standard image sizes to build a srcset, it’s time to get acquainted with WordPress core’s new responsive image functions11 by applying viewport-based image selection to a theme. For this example, we’ll look at a full-width banner image that appears on a static front page.
Let’s assume that we have an existing website using the current version of WordPress and that support for post thumbnails is enabled12 in our theme. (Support for post thumbnails allows us to add featured images to posts and pages.) Let’s also assume that the banner image is pulled from the featured image for the front page. If our front page template uses WordPress’ the_post_thumbnail() template tag to generate the HTML for the banner, then we are all set: This function already outputs an img tag that includes srcset and sizes attributes. That’s one reason why it is good to use WordPress template functions when they are available!
Maybe, though, our page template builds the HTML for the banner image piece by piece, as you might need to do if your banner is actually part of a third-party carousel. To make this image responsive, we ask WordPress explicitly for srcset and sizes attributes, using the wp_get_attachment_image_srcset() and wp_get_attachment_image_sizes() functions, respectively:
<?php if ( has_post_thumbnail() ) : ?> $id = get_post_thumbnail_id(); $src = wp_get_attachment_image_src( $id, 'full' ); $srcset = wp_get_attachment_image_srcset( $id, 'full' ); $sizes = wp_get_attachment_image_sizes( $id, 'full' ); $alt = get_post_meta( $id, '_wp_attachment_image_alt', true); <img src="<?php echo esc_attr( $src );?>" srcset="<?php echo esc_attr( $srcset ); ?>" sizes="<?php echo esc_attr( $sizes );?>" alt="<?php echo esc_attr( $alt );?>" /> <?php endif; ?>Here, we’ve based srcset and sizes on the original image size by passing the full keyword to our functions. If that image is 1280 × 384 pixels, and if we keep the standard image sizes at their default values, then the HTML output would look like this:
<img src="banner.jpg" srcset="banner.jpg 1280w, banner-300x90.jpg 300w, banner-768x231.jpg 768w, banner-1024x308.jpg 1024w" sizes="(max-width: 1280px) 100vw, 1280px" alt="Front page banner alt text"> In this case, as in the last, the value that WordPress gives us for the sizes attribute is acceptable for our hypothetical layout. In general, WordPress’ default value for sizes works fine for full-width images, but for any other layout, you are going to need to write the value yourself. Some layouts are more complicated than others: The sizes attribute for a responsive image grid (see Eric Portis’ example13) is pretty straightforward, but layouts that change at different breakpoints, such as pages with a sidebar column, require more thought. For the latter case, Tim Evko uses the Twenty Sixteen theme as an example of applying the wp_calculate_image_sizes filter14 to make the sizes value match the layout’s CSS breakpoints.
Let’s momentarily revisit the HTML in the banner example and take note of the size of the smallest image in srcset: It’s only 90 pixels tall and probably difficult to discern. The aspect ratio is fixed by the original image, so, realistically, we’ll be looking at a 96-pixel stripe across a 320-pixel phone.
Themes currently get around the “banner stripe” problem by displaying the banner image as the CSS background of a flexible div and adjusting its height and background-size in media queries. This solution is responsive in terms of appearance, however, it is not a true responsive image solution. Enter art direction, the ability to provide different image sources at different viewport widths directly in HTML. With this technique, we can avoid the banner stripe problem by resetting the proportions of an image below a breakpoint to give the smallest resizes better dimensions; we can also use art direction to emphasize a particular area of an image at different sizes or orientations.
In our art direction example, we will use the 1400 × 952-pixel image from our first example to create a responsive hero image. On large viewports, the hero image will look like this (albeit much larger):
15But for smaller viewports, we will crop the image within WordPress so that it looks like this:
18This approach gives us two images for the price of one — a full-sized and a cropped — each with its own srcset.
Setting up our WordPress environment for art direction takes four steps. As in the previous example, the hero image will be the featured image for the website’s home page, and we’ll be editing the front-page template. I assume that you are making changes to an existing theme and, thus, have created a child theme19 to work in.
We are going to code our hero image by wrapping it in HTML5’s picture element20. The picture element allows us to provide multiple sources for an image, along with media queries to determine when a source will be used. As of this writing, picture is supported globally by 62% of browsers21, so we will need to rely on the Picturefill polyfill22 to implement this element in non-supporting browsers. The Picturefill project is maintained by the Filament Group, and the Picturefill JavaScript file can be downloaded from GitHub23.
To include the PictureFill script in the head of our pages, we’ll place the script file in our child theme directory and add the following code to our child theme’s functions.php file:
// adds Picturefill to 'js' subdirectory inside child theme function theme_add_javascripts() { wp_enqueue_script( 'picturefill-js', get_stylesheet_directory_uri() . '/js/picturefill.min.js', '', '', false ); } add_action( 'wp_enqueue_scripts', 'theme_add_javascripts' ); To plan our srcsets, we need to decide on three things:
Let’s deal with each in turn:
The breakpoint
For our example, let’s say that the couple in the rearview mirror become hard to recognize in images narrower than 768 pixels; perhaps some overlaid text that we are using with this image no longer fits beneath the mirror at this point as well. We’ll set our breakpoint at 768 pixels, which means that we’ll also be able to keep the “medium_large” and “large” image sizes at their default values.
The aspect ratio
This simple implementation of art direction in WordPress doesn’t require us to upload multiple featured images or to type in a value for the breakpoint. Still, we need a way to keep the srcset for the full-sized image from overlapping with the srcset of the cropped image, and for this we will rely on the fact that the wp_get_attachment_image_srcset() function only selects image files with the same aspect ratio as the size we pass to it. We’ll pick a 5:3 (1.67) aspect ratio for the cropped hero image, which differs from the 1.47 aspect ratio of the original.
The image sizes
Based on our breakpoint and aspect ratio, the size of the cropped hero image will be 767 × 460 pixels. The cropped hero won’t be completely responsive, however, unless we define additional image sizes to crop along with it. Applying a performance budget approach24 to our hypothetical theme, we’ll create custom sizes that are 560 and 360 pixels wide, giving us a roughly 20 KB difference in file size between the three cropped versions. (Because the file size of a compressed image depends its color variation and level of detail, I established this size relationship empirically with WordPress’ default 90% JPEG compression.) The custom image sizes will be created by adding the following code to our child theme’s functions.php file:
// cropped hero add_image_size( 'mytheme-hero-cropped', 767, 460, true ); // scaled-down cropped hero 1 add_image_size( 'mytheme-hero-cropped-smaller', 560, 336, true ); // scaled-down cropped hero 2 add_image_size( 'mytheme-hero-cropped-smallest', 360, 216, true ); The fourth parameter in the add_image_size function specifies whether the image version can be hard-cropped, which we set to be true; many cropping plugins (which we’ll look at in step 3) will not let us hard-crop an image unless this is set.
Overall, we’ll have the following image versions available to work with:
| Size | Width (px) | Height (px) | Aspect ratio (w/h) |
|---|---|---|---|
| Full-sized hero: | |||
| full (original) | 1400 | 952 | 1.47 |
| large | 1024 | 696 | 1.47 |
| medium_large | 768 | 522 | 1.47 |
| medium (not needed) | 300 | 204 | 1.47 |
| Cropped hero: | |||
| mytheme-hero-cropped | 767 | 460 | 1.67 |
| mytheme-hero-cropped-smaller | 560 | 336 | 1.67 |
| mytheme-hero-cropped-smallest | 360 | 216 | 1.67 |
| Thumbnail: | |||
| thumbnail (not needed) | 150 | 150 | 1 |
WordPress’ built-in image editor does allow us to hard-crop an image, but the change is applied to all image sizes (or just to the “thumbnail”), whereas we need to crop only three. For greater control, we’ll install a third-party cropping plugin from the WordPress directory.
While any cropping plugin should work with our art direction scheme, the ideal plugin would be able to crop multiple versions of an image at the same time, provided that they all had the same aspect ratio. I came across two plugins that are able to do this: Crop-Thumbnails25 and Post Thumbnail Editor26. Testing both of these plugins with our custom image sizes, I found that the Crop-Thumbnails plugin (version 0.10.8) recognized only two of the three sizes as having the 5:3 aspect ratio, meaning that I would need to go through the cropping process two times. (The “mytheme-hero-cropped” size was left out because of a rounding issue: An exact 5:3 aspect ratio would require the width to be 460.2 pixels, instead of 460.) The Post Thumbnail Editor plugin (version 2.4.8) allowed me to crop all three sizes at once.
Now that our images are ready, we can add the code for the hero image to a copy of the front-page template in our child theme. HTML5’s picture element can hold an img tag and one or more source tags. For our example, the single source element will contain the media query and srcset for the full-sized image, and the img tag will contain the srcset for the cropped image; the cropped image will serve as the default image when the breakpoint condition is not met.
<?php if ( has_post_thumbnail() ) : ?> $id = get_post_thumbnail_id(); $alt = get_post_meta( $id, '_wp_attachment_image_alt', true); /* get the width of the largest cropped image to calculate the breakpoint */ $hero_cropped_info = wp_get_attachment_image_src( $id, 'mytheme-hero-cropped' ); $breakpoint = absint( $hero_cropped_info[1] ) + 1; // pass the full image size to these functions $hero_full_srcset = wp_get_attachment_image_srcset( $id, 'full' ); $hero_full_sizes = wp_get_attachment_image_sizes( $id, 'full' ); // pass the cropped image size to these functions $hero_cropped_srcset = wp_get_attachment_image_srcset( $id, 'mytheme-hero-cropped' ); $hero_cropped_sizes = wp_get_attachment_image_sizes( $id, 'mytheme-hero-cropped' ); <picture> <source media="(min-width: <?php echo $breakpoint; ?>px)" srcset="<?php echo esc_attr( $hero_full_srcset ); ?>" sizes="<?php echo esc_attr( $hero_full_sizes ); ?>" /> <img srcset="<?php echo esc_attr( $hero_cropped_srcset ); ?>" alt="<?php echo esc_attr( $alt );?>" sizes="<?php echo esc_attr( $hero_cropped_sizes ); ?>" /> </picture> <?php endif; ?> There are two additional points of interest in this code. First, notice that we are not hardcoding the breakpoint width, even though we know that it should be 768 pixels in this case. Because we calculate the breakpoint using the width of the largest cropped image, we can now change the image sizes in future without needing to go back to edit the template. Secondly, in contrast to the banner image example, the img tag here does not get a src attribute. This is an artifact of using a polyfill to support the picture element: A non-supporting browser would preload the file given in the src attribute, resulting in a double download for this image.
The HTML that we get is shown below:
<picture> <source media="(min-width: 768px)" srcset="hero.jpg 1400w, hero-300x204.jpg 300w, hero-768x522.jpg 768w, hero-1024x696.jpg 1024w" sizes="(max-width: 1400px) 100vw, 1400px"> <img srcset="hero-767x460.jpg 767w, hero-560x336.jpg 560w, hero-360x216.jpg 360w" alt="Front page hero alt text" sizes="(max-width: 767px) 100vw, 767px"> </picture> We could finish here, but we could make one refinement to our HTML output. Notice that the 300-pixel-wide “medium” image has been included in the srcset for the full-sized image. This image file will never be used, so we can add a wp_calculate_image_srcset filter to remove it from the srcset. The following code, which goes in the child theme’s functions.php file, looks only at the potential srcset (the $sources array) for the full-sized hero image; it loops through the images and removes those with widths narrower than the breakpoint.
add_filter( 'wp_calculate_image_srcset', 'mytheme_remove_images_below_breakpoint', 10, 5 ); function mytheme_remove_images_below_breakpoint( $sources, $size_array, $image_src, $image_meta, $attachment_id ) { if ( is_front_page() && has_post_thumbnail() ) { // check if we're filtering the featured image if ( $attachment_id === get_post_thumbnail_id() ) { // get cutoff as width of the largest cropped image size // (in HTML, breakpoint = cutoff + 1 ) $cutoff = $image_meta['sizes']['mytheme-hero-cropped']['width']; // check if our version is the full-sized version by // comparing its width to the cutoff if ( $cutoff $value ) { // if image width is at or below cutoff, // we don't need it if ( $cutoff >= $key ) { unset( $sources[ $key ] ); } } } } } return $sources; } We have just set up a WordPress theme to support art direction in a simple manner. This method relies on WordPress’ standard administration interface as much as possible, and it requires only a single image to be uploaded. Simplicity comes at a cost, however, and this method has its limitations: The sizes for the cropped hero images are hardcoded in the theme, only one breakpoint is assumed, and the aspect ratios of the full-sized and cropped heros must be different.
Programmatically, it is entirely possible to give a website’s content creator complete control over all aspects of art direction, because the wp_calculate_image_srcset filter can process images by width, size keyword or any other bit of meta data that a theme or plugin wants to save. Multiple images could even be selected from the media library and incorporated in the art-directed version. The challenge lies in making the administration interface — the theme customizer or the plugin settings page — simple to use for content creators who may want no options, a few options or the kitchen sink.
Finally, we can’t end an article on responsive images in 2016 without mentioning browser support. While we do have a very effective polyfill for the picture element, if a browser that does not natively support the srcset attribute has JavaScript turned off (or encounters a JavaScript error), a visitor will only see our hero image’s alt text. Global support for the picture element did increase earlier this year when new versions of Safari for Mac and iOS were released, but we are still waiting for the picture element to come to UC Browser and for older browsers — namely, Internet Explorer 11 — to die out.
(vf, al, il)
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
↑ Back to topTweet itShare on Facebook
We all love a good wallpaper to polish up our desktops. So to provide you with fresh artwork on a regular basis, we embarked on our desktop wallpapers mission1 eight years ago. Each month we challenge you, the design community, to get your creative juices flowing and produce some inspirational and unique desktop wallpapers.
And, well, also this time designers and artists from across the globe challenged their artistic abilities and contributed their designs for September. The result is a collection of desktop wallpapers that are a little more distinctive than the usual crowd. All of them come in versions with and without a calendar and are free to download. A big thank-you to everyone who shared their artwork! Now, which one will make it to your desktop?
Please note that:
“The earth has music for those who listen. Take a break and relax and while you drive out the stress, catch a glimpse of the beautiful nature around you. Can you hear the rhythm of the breeze blowing, the flowers singing, and the butterflies fluttering to cheer you up? We dedicate flowers which symbolize happiness and love to one and all.” — Designed by Krishnankutty3 from India.
“Clean, minimalistic office for a productive day.” — Designed by Antun Hiršman46 from Croatia.
47“Penguins are sociable, independent and able to survive harsh winters. They work as a team to care for their offspring and I love that!” — Designed by Glynnis Owen67 from Australia.
68“Autumn can be best described with the colorful woods where all colors mix and where you can see the great creations of nature.” — Designed by S7 Design92 from Serbia.
93“Summer is coming to an end in the northern hemisphere, and that means Autumn is on the way!” — Designed by James Mitchell137 from the United Kingdom.
138“My wife tells me ‘You have a song for everything!’ and this month was no exception. Earth, Wind, and Fire’s happy, danceable tune was the first thing to come to mind. For me, the catchy beat and memorable lyrics are such a contrast to the month that heralds the first day of Autumn, ushering in a ‘temporary death’ yet with a certain, not-too-distant re-quickening. It’s the 22nd this year, so we took liberties with that excerpt. Ironically, co-writer Allee Willis claims no significance to the date, stating, in an interview with npr.org, ‘It just sang better.’” — Designed by Brian Frolo158 from Cleveland, Ohio, USA.
159Designed by PJ Brown177 from the United States.
178“September marks the arrival of autumn and is one of the most beautiful months of the year. Autumn — this is a great time for inspiration and creation. The arrival of autumn hits us in the heart, and as the trees turn yellow we begin to notice how quickly time passes by. In September, the sun shines gently, but hedgehogs are preparing for hibernation.” — Designed by Anastasia220 from Russia.
221“This month is Mexico’s independence day and I decided to illustrate in my wallpaper one of the things Mexico’s best known for: the Lucha Libre.” — Designed by Maria Keller249 from Mexico.
250“September is the start of spring in Australia so this bright wallpaper could brighten your day and help you feel energized!” — Designed by Tazi Design302 from Australia.
303“The dragonfly flies for a short time and enjoys it to the fullest. Be like the dragonfly, love your life and live in the moment!” — Designed by Denise Johnson327 from Chicago.
328“The month of September starts with the arrival of festivals, mainly Ganesh Puja.” — Designed by Sayali Sandeep Harde342 from India.
343Designed by Sabrina Stern371 from Costa Rica.
372Please note that we respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience throughout their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us, but rather designed from scratch by the artists themselves.
A big thank you to all designers for their participation. Join in next month394!
What’s your favorite theme or wallpaper for this month? Please let us know in the comment section below.
(cm)
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
↑ Back to topTweet itShare on Facebook
Prototyping is essential to help your team create the best product possible. It’s a chance to experiment with ideas and turn them into something tangible that you can test and build upon. When you fail with your prototype, you land softly — there’s always the chance to iterate and improve.
The team behind Adobe’s new prototyping tool Experience Design1 (Adobe XD) uses prototyping as a method to test new features before they make it into the program. Being a product manager on the Adobe XD team, I’ll share some insights into how the team uses prototyping to build and improve Adobe XD, and make prototyping more efficient for designers.
Prototypes are about communication and hypothesis testing. They give teams a way to experiment something that’s tangible, shortening the psychological distance between the user and the solution.
“A prototype is worth a thousand meetings.” — an IDEO saying.
We build prototypes to learn, solve conflicting ideas, start conversations, and manage the building process. It helps teams to build empathy, to collaborate, to explore options (and barriers) that only become visible when you build something, to test and to be inspired.
There’s research to support the theories that you can “build to think” or “write longhand to remember”, which means that if you use your hands, more neurons are utilized to process the task in your brain, making you “think better” or “remember more”.
The biggest benefit always goes back to risk. The sooner we “fail” and the faster we learn, the greater the chances are for success.
It’s cheaper to fail early in order to validate things that work and things that don’t. That’s why we build prototypes for every major product feature. We test with pre-release users and key customers very early on and definitely before we get to implementation. And yes, we do “fail” a lot, which is great! It’s great because we learn a ton in the process and minimize the risk of failure in the long run. In the end, we tackle real customer needs, with empathy, in an innovative way.
Absolutely! One of the fun prototyping exercises I use to warm design teams up is called “Dark Horse”. From your Design Thinking brainstorm6, pick the craziest idea, the one that’s almost impossible to become a reality; and as a team, build a prototype for it.
7
9Warning: crazy and funny things WILL happen!
11You can guarantee oxytocin will be released; team members will bond and connect more.
Not too long ago, a small group of very talented designers, engineers, and product managers got together, to prototype what a new solution for designers trying to communicate their message could be. After many different brainstorming sessions, instead of starting from scratch, they used bits of existing prototypes to string together a foundation to explore and experiment with new tools and approaches in a design tool.
This initial prototype grew and new tools were created, validated, fine-tuned and validated again to become Project Comet. In 2016, with a much larger team that includes designers, engineers, product managers, program manager and interns, we came together and met with leading agencies and up and coming designers to focus on solving the UX challenges of today and tomorrow.
As soon as the first prototype was validated, then changed and validated again, we started developing Adobe XD as a native application. First for Mac OS and later for Windows. Additionally, we’re working on a companion app for iOS and Android, for designers to preview their designs in real-time.
In October 2015, at Adobe MAX13, Anirudh Sasikumar14, an engineer working on Adobe XD, demoed a prototype where designers could use the tool to feed designs with real data coming from different sources, such as the Finder and Web, for text and imagery. His Medium post15 covers the features in details.
16I spoke with Anirudh recently, asking how he came up with it and how the prototype helped him validate the approach.
According to him, it’s very common for developers to bind systems to data. Something that’s not true for designers, always needing to use fake data to simulate how the design would behave in the real world.
Anirudh explained the catalyst for designing with real data was the Repeat Grid tool. As soon as we finished building it, it was natural to start thinking about bringing more data in. The design community had already expressed interest in “Designing with data” and numerous workarounds in achieving the same using plugins/extensions.
Thanks to a delay on Caltrain, he started coding the functionality. Having some of the use cases in mind, implementation was easy. By the end of the trip, he had a working version of it. Not polished, but enough to show promise and to be validated.
The magic of prototyping is being able to see all the possibilities and edge cases around it. It’s not in your head anymore, it’s there, closer to reality. You can see so much more!
You can also see walls, problems that never surface before you actually build it. For instance, connecting with Google Sheets was tricky.
17Phase 1 is complete and available for Mac OS, where designers can drag text files from Finder, to feed a Repeat Grid. The next phase will focus on sample data and bringing content from the Web.
If you want the feature in Adobe XD, feel free to upvote here18.
Let me start with the same question we asked hundreds of designers:
Do you need layers?
Initially, we started with the assumption that people didn’t need layers, especially the way layers were presented for so many years in Photoshop or Illustrator. It was a big challenge, because a big number of experienced designers took years to build those mental models.
At Adobe XD, in order to deliver innovation, we challenge existing mental models frequently.
Based on that initial research, Talin Wadsworth19, the lead designer for XD, came up with the concept of local layers. To validate the concept, we worked together to set the context and test the prototype with prerelease users and key customers.
20After a long research and validation process using a prototype to drive conversations, and after multiple adjustments, we confirmed that our customers need layers for exporting and to organize complex designs.
We have started the work to implement this new mental model.
Soon, designers from all over the world will tell us if we got it right. Fingers crossed!
Since day one, we build and test prototypes of every major feature before we implement them. A prototype is an extremely powerful tool to help teams “see” more, experience more, “fail” more, learn more and, in the end, pivot faster to where the secret for success is.
A quote from the book Zero to One sums up the benefit of prototyping well:
“It’s like the world is full of secrets for disruptive success, just waiting for someone to find them”.
Who is going to create the next Uber, or the next Facebook, or even the next Pokemon Go app? Building and testing prototypes can help you get there, faster!
As a suggestion, please remember that Adobe XD can support you and your team when building prototypes for websites or mobile applications. Have you tried it? It’s free: http://xd.adobe.com22. What are you waiting for? Start building prototypes now!
↑ Back to topTweet itShare on Facebook
Designers, developers and managers often work with compressed timeframes and multiple projects simultaneously. A team must be able to respond quickly to feedback on their product from clients, project managers and developers. Each minor revision in the UI or UX needs to be reflected in the documentation, so that designers and developers always have the latest information.
A style guide ensures that your project doesn’t encounter serious problems when you implement the initial design. Making sure that all specifications are accurate to their designs is critical, because an inaccurate specification means that developers will have to either rely on guesswork when building the app or go to the design source to get answers to their questions. Transferring all of this information manually to the developers can be a headache and usually takes significant time, depending on the extensiveness of the designs.
In this article, we’ll review the process of creating a style guide, the process of handing off a design, and collaboration across the whole team. We’ll also walk through an example workflow, demonstrating how developers and designers can improve cross-team communication and drastically reduce iteration time.
A project consists of designers, developers and project managers, and each area has its own particular needs.
When a designer prepares a design, they hand it over to the developer. What they usually do is export some PNGs and prepare a specification with all of their annotations. Specifications can be stressful in a big project, and the design of an interface layout can change quite often. Thus, a traditional style guide will pretty much get outdated almost immediately.
Preparing specifications is tedious — we know that. Manually doing it is time-consuming, and every designer does it a little differently. Most designers spend more time making specifications than actually designing. And they often have to manually export all of their assets for developers. I can tell you that every designer is tired of that.
If you want to save the designer’s time, just tell them to forget about that and focus on the actual design process instead. Every minute a designer spends revising documentation is a minute lost that they could be spending really nailing the visuals, experience and interactions.
Inspecting specifications is painful. Developers will usually ask the designers for every little detail contained in the design or, worse, are forced to do it themselves in Photoshop or Sketch. In most cases, they need to manually convert all sizes of the assets according to the platform’s requirements (for example, converting pixels to density-independent pixels, scale-independent pixels, points, etc.). They often don’t have enough detailed information about the visual design and have to guess, resulting in visual inconsistencies.
Even when the developer has successfully implemented the design, there is still the possibility that the designer will make a change, at which point the developer would have to manually inspect the design again and figure out what exactly has changed. Not flexible at all!
Project managers are always trying to find ways to improve collaboration between designers and developers, because everyone on the team should be on the same page for every design change. If you’re working with a remote team, you’re probably going to need some online space to collaborate and meet, a single channel of communication. Modern communication tools such as Slack make that possible, but the project managers still need to track progress and provide feedback on what has changed and where. They are well familiar with messy email attachments and feedback coming from multiple places.
They also need to figure out the current state of the product very quickly. They need to stay on top of the design process by reviewing changes, comparing versions visually side by side, and discussing them in real time in one place.
Creating design specifications involves identifying colors, x and y values, fonts, text weights, distances, positions and a number of other characteristics of the assets. Each asset carries certain characteristics that need to be recorded.
You need a tool to bridge the gap between the design and coding stages of development, a tool that simplifies and speeds up the specification and development process, a tool that provides a single entry point for all design-related stuff, so that you (the designer, developer or manager) don’t have to think about where to find the latest version of the design. This will result in products getting built and shipped faster.
Thankfully, tools exist out there to help with this. Each of them takes in Photoshop or Sketch documents and produces a specification for developers, including code snippets and image assets. These tools also track changes between versions of the design.
This is where Avocode1, Sympli2, and Zeplin3 enter the scene. These are collaboration tools for UI designers and front-end developers. They are built for the process of going from Photoshop or Sketch to code. You can upload designs and turn them into specifications and guidelines that are tailored to the platform you are working on. Using these tools, you can:
Last but not least, designers and developers will essentially work in a shared workspace, where elements such as sizes, distances, fonts and icons move seamlessly back and forth, without requiring a large design file annotated with what the designer needs.
However, as I’ve said, these tools are for inspecting, not editing or interactive prototyping. This is important. These are not image editors, and they don’t allow you to create designs or prototypes. You still need to create and edit your files in Photoshop or Sketch and then open the files for inspection in one of these tools.
Avocode is one of these tools that bridge the gap between web designers and developers. The process of creating a website starts with designing in Photoshop or Sketch; however, when the designer is finished and the front-end developer has to implement the design, the design file is broken down into images, colors, sizes, CSS, etc.
Before doing anything in Avocode, you need to create an account6. A free two-week trial of the application is available on the website.
7Avocode contains two parts: a web-based manager and a desktop application. It works based on projects, and you need to create a project to get started. A sample web project (a landing page) is provided to help first-time users understand what features are available.
9After creating a project, you need to upload your design. You can use Dropbox or manually drag and drop files from your local system.
11
13After creating a project and uploading your designs, you need to install the desktop application to inspect them. The web app only has previewing and commenting features and doesn’t allow you to inspect a design in detail.
15So, let’s dig into the details of the desktop app! Avocode feels like a powerful and professional application. The UI looks very similar to Photoshop — same color scheme and typefaces. The dark Photoshop-like interface makes Avocode look and feel really slick. If you’re an intermediate Photoshop or Illustrator user, the learning curve is close to none.
The main tab you’ll be focusing on and working with most of the time is “Project Designs.” It shows each of your projects in the form of a thumbnail, title and activity indicator.
17If you double-click on a thumbnail, you’ll immediately see a screen with a full list of groups and layers, exactly like Photoshop. On the bottom is a set of Avocode tools. The first one we will use is the Select tool. With it, you can select individual layers, or multiple layers, and see its properties on the right side. You will notice that the inspector’s content changes based on which item is selected.
19Below, the layer for the call-to-action button is selected. When you select an item in your PSD, the sidebar shows the CSS for that item. As a bonus, Avocode also gives you the option to copy LESS or Sass code:
20You can select an image and see its dimensions. The image-exporting options in Avocode are really nice, too. You can set up different rules that allow you to export all of your images in any number of configurations, including JPG, PNG and SVG formats, as well as with the right proportions (“1x” means the original size).
22The info panel has all of the important information about the design. You can even get a public link to share the design with anyone. What’s best is that this panel lists all of the fonts used, with links to Typekit and Google Web Fonts so that you can easily use them in your project.
The Measure tool is useful. Select a layer and then hover over other layers to see their positions relative to the first layer. Below is a selected layer with a “Get started now” button, and its relative position to the top, left and right.
24The next one is a color picker, which basically takes a color and copies its hex value to your clipboard. You can add this color as a variable to your design. With this tool, you can quickly create a color scheme for your design.
26The final tool is Slice, which makes it possible to export a selected part of the design as an image or style scheme.
28The good thing is that each tool has a hotkey combination, which is handy for users who use the keyboard to quickly switch between options.
Another cool feature of Avocode is the use of guides. However, a first-time user might wonder whether this option is available because the feature is hidden behind a little button in the bottom-right area of the screen. Avocode supports both user-created guides as well as designed guides that have already been made in Photoshop or Sketch. So, if your Photoshop document has guides, they will show up in Avocode.
30Using Avocode, you can visually compare revisions of designs easily. You can access this feature in the “design detail” of your project in the web app:
Avocode lets you leave notes in a specific area in the design, allowing you to discuss design changes with anyone in one place instantly.
Simply click or drag anywhere in the design to highlight the area you want to talk about, then write your message, and hit the submit button. Everyone will instantly get a notification:
Avocode charges $10 per month per user for the business plan, which has integration with Slack and permissions management. If your team consists of one to three people and you don’t need permissions management, you can choose the “Garage” plan, which costs $7 per month per user.
Sympli isn’t just a design handoff or collaboration tool — it’s a complete collaboration platform that covers the entire product design team, including design handoff features for designers coming from Photoshop (Adobe XD coming soon) and Sketch, as well as automated implementation features and tools for developers in its Android Studio and Xcode plugins. Recently launched this spring, it’s a great tool that has done a lot to speed up the design and development process.
32One of the biggest reasons to use Sympli is its integration with Xcode and Android Studio, making it a tool for the whole team because it goes beyond design handoff to help developers with automated implementation.
34When users visit the Sympli website36, they are immediately oriented with the “How it works” section, which tells the user what they need to know to get started and familiarizes them with the product. First, sign up and create a new project. Select the project type (Sympli supports web, Android and iOS projects) and the resolution (@1x, @2x or @3x). After that, you will be able to upload you designs.
37Sympli works as a plugin in Photoshop or Sketch; however, like in Zeplin, you can’t directly upload native design files. Sympli is cloud-based, so it works across platforms. And for those security-conscious companies that prefer not to use the cloud, Sympli offers enterprise options for on-premise setup.
Compared with Avocode and Zeplin, Sympli has an interesting option for exporting assets.
39Sympli for Sketch is a native plugin, which has some additional benefits, such as the ability to export hidden assets (in case you have multiple states of the same control on the artboard) and validation of asset names to conform with the destination platform’s requirements. This means Sympli not only will generate assets with all of the required formats and sizes in platform-specific units for the marked layers or groups, but will also validate all specified names, handle asset name duplicates, export hidden assets and even help you to stay within the asset-naming requirements for Android or iOS.
41Developers can also apply naming-convention rules for their assets, so that renaming rules get applied every time a designer sends assets.
Collaboration in Sympli starts before the design handoff. Several designers can work on a project at the same time and can export screens to the same project. Once the designs are uploaded, the project owner invites people using a shareable link or sends it directly to the team members’ inboxes. If you are updating an existing project that has already been shared, the team will be notified about the updates.
43Sympli doesn’t have a separate desktop application; the powerful web app has all of the required functionality. Mockups are accessible via IDE extensions (Xcode or Android Studio). You can always access the latest version of the design mockups, and designers can send links to particular screens, rather than files, so that recipients don’t have to dig up those screens themselves.
45Sympli automatically stores all colors and fonts in a project’s “Summary” section. It finds multiple instances of the same color or font used in multiple layers, groups them in an expandable list of styles, and generates the names for them automatically. It also allows users to rename colors and sync the changes.
47Sympli not only specs the fonts used, but also shares font files through its Brandbooks feature. Designers can attach font files to a project to be made available to developers right away, along with collections of company-named colors. Font files can be attached to multiple projects.
49All colors and fonts are presented in platform-specific notation, so that you don’t have to change them manually. Also, Sympli provides access to assets in bitmap or vector format; the developers chooses which, and both formats are generated on the fly, automatically.
51You can visually compare revisions of designs easily. To access this feature, open the design detail in Sympli and click the “Version” link. However, a new mechanism for comparing versions is coming soon, which will highlight changes and show versions side by side.
53The first tool we will look at is Layers. With it, you can select individual layers or multiple layers and review properties on the right side. You will notice that the inspector’s content changes based on which item is selected.
55One of the best features of Sympli is the Ruler, a very useful measurement tool. Click on any element in the layout and track its relative position to the other elements. The measurements are presented in platform-specific units (depending on the destination: points for iOS, density-independent pixels for Android, and pixels for web projects).
57Sympli has a commenting tool, named Spots, that facilitates collaboration and helps to clarify points of confusion late in the design process.
59Sympli seamlessly integrates with Slack. Whenever someone leaves a note or updates the design, a notification is posted to the Slack channel.
As mentioned, a big difference with Sympli is its extensions for the Android Studio and Xcode development environments. Sympli integrates fully with both IDEs, allowing you to bring designs and mockups from Photoshop and Sketch right into the environment where developers are working.
61The IDE extensions provide several cool features, such as smart asset synchronization, which is a visual dialog that makes it possible to merge assets, showing you what is currently in the project and what you’ll have after the assets are synchronized. You can include or exclude individual assets.
63A mind-blowing feature is the visual implementation of designs as storyboards. Basically, developers can drag and drop designs from mockups into interface-builder views, and the views will be styled in exactly the same way as the mockups, including both configuration and runtime properties:
You can even drag and drop styles from a design mockup right into a storyboard.
While Sympli automates code and tasks, it doesn’t introduce any third-party dependencies into a project, nor does it introduce any changes in the technical process. So, developers aren’t forced to use any frameworks or introduce any libraries into their projects.
Sympli charges based on the number of projects. The free plan covers one active project. The “Pro” plan is most common, with a price of $25 per month, which allows eight active projects to be run simultaneously. Each paid plan includes an unlimited number of collaborators and archived projects, along with great tech support.
Zeplin is the last collaboration tool for UI designers and front-end developers we’ll be looking at. When a designer exports Photoshop or Sketch files to Zeplin (by selecting the artboard and pressing Command + E), all of the styles are communicated to the developers. In other words, the specification sheet is automated, similar to Sympli.
When you enter the Zeplin website65, you’ll immediately notice delightful details, such as the fun cartoon zeppelin logo. Little details like these provide visual stimulation and delight.
66Onboarding consists of a basic tutorial video, which users see upon signing up. The video has enough information to get you started.
67As with Avocode, users have to install a desktop application. Then they are asked what type of project they would like to create. Unlike Avocode, Zeplin supports not only web projects, but also Android and iOS. Let’s choose iOS.
69Now it’s time to upload some designs. Zeplin has a powerful and delightful empty state, telling you what to do next.
71Zeplin doesn’t allow you to directly upload designs, and it works only as a plugin within Photoshop or Sketch, again similar to Sympli. Normally when you launch Zeplin, the plugin should be installed automatically, so uploading designs is only a couple of clicks away. In Photoshop and Sketch, you can export a whole design or individual objects.
73To see your assets in Zeplin, mark the layers as “exportable.” Again, the empty state will guide you step by step:
75Once the designs have been uploaded, the project owner can invite people using a shareable link or send the link directly to the team members’ inboxes.
77If you want some feedback on your designs or style guide, you can also use the sharing icon, next to the “Scene” menu item. You’ll see a dialog like the one below, which clearly explains how it works and even links to sample data.
79Productivity apps tend to be dry and lack any sort of personality. But Zeplin has managed to make the boring process of coordinating feedback somehow enjoyable. As soon as you upload your designs, they are turned into specifications and guidelines tailored to the platform you are working on (in our case, iOS).
Unlike Avocode and Sympli, Zeplin doesn’t have a special set of tools for working with a design. It’s more of a viewing app, with asset-exporting capabilities and team-collaboration features. Developers can select a layer and see its size and all other necessary information (in the case of a text field, you would see the font’s name, size and color).
81As you can see, all measurements are displayed in points (which iOS developers require). Also, all projects in Zeplin have a color palette, allowing you to name the selected colors.
83If you’ve made image assets exportable in Sketch, you’ll see them in “Assets” in Zeplin:
85The colors and fonts used in a project are displayed in the “Styleguide” tab. You can rename these colors and export them if you plan to use them in your project. In general, this makes designing for iOS and Android Studio way more pleasant!
87Developers can see, copy or download the CSS for web projects, the XML resources for Android projects, and the UIFont and UILabel extensions for iOS, both for the color variables and text styles, in the “Styleguide” section. Below are two examples:
89
91Because its available as a standalone app as well as a web app, you can access Zeplin pretty much anywhere. Every screen in Zeplin has a link, which you can find in the right panel of the screen. So, if a team member has not installed the desktop app, they will still be able to see the project in the web application.
93Last but not least, the tool’s annotation features allow team members to comment on parts of the app and use the result as a road map. This also helps to clear up any confusing parts of the specification process and preserves a record of the notes taken for anyone to review.
95This streamlined process makes life so much easier for everyone involved.
Zeplin’s price is based on the number of projects. A free plan is available for single projects. The most common plan is “Growing business,” with a price of $25 per month to run eight active projects simultaneously. All plans include unlimited team members.
97Selecting the right product is always difficult, especially when you have several good options (as we do). All of the tools we’ve looked at are amazing, and I believe you’d enjoy using any. That being said, here are some tips to help you select the most suitable one:
All three tools focus on the pain points that designers and developers experience when working together. The tools cater to those two very different types of users with different functionality. But each balances those needs beautifully and helps teams iterate quickly by providing living, breathing, interactive specifications.
Say no to clunky, difficult-to-understand, flat specifications that take forever to generate. We now have tools to easily and accurately translate the vision for an app into the measurements needed to code it. This interactive approach to specifications allows teams to spend more time on what’s important: creating beautiful and functional designs and giving users the best possible experience.
(il, al)
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
↑ Back to topTweet itShare on Facebook
Have you ever opened a website, started reading and, after some time had passed and all assets had finished loading, you found that you’ve lost your scroll position? I undergo this every day, especially when surfing on my mobile device on a slow connection — a frustrating and distracting experience.
Every time the browser has to recalculate the positions and geometries of elements in the document, a reflow happens. This happens when new DOM elements are added to the page, images load or dimensions of elements change. In this article, we will share techniques to minimize this content shifting.
When a website loads, it takes some time until the images are loaded and the browser is able to calculate the space needed. The following GIF, recorded with the throttling set to 3G, demonstrates the effect.
One way to avoid this is to set a fixed width and height for all images, but this isn’t practical for responsive websites because we want images and videos to adapt to the available space.
With intrinsic ratios1, also referred to as the padding-bottom hack, we can define the sizes that our media will occupy.
The formula for getting the value for padding-bottom is this:
(height of the asset / width of the asset) * 100(%) If we have an image with a width of 1600 pixels and a height of 900 pixels, then the value would be this:
(900 / 1600) * 100(%) = 56.25% Here is a Sass mixin we can use to define the aspect ratios of our images, videos, iframes, objects and embedded content.
@mixin aspect-ratio($width, $height) { position: relative; padding-bottom: ($height / $width) * 100%; img, video, iframe, object, embed { position: absolute; top: 0; left: 0; right: 0; bottom: 0; } } .ratio-sixteen-nine { @include aspect-ratio(1600, 900); } <figure> <img src="waterfall.jpg" alt="Waterfall in Iceland"> </figure> To make the experience even better, we can style the placeholder by adding a background to the wrapper.
figure { background: #ddd url(camera-icon.svg) no-repeat center center; } For images, we can use an icon to indicate to users that an image will appear. By implementing aspect-ratio placeholders, the user can decide whether to wait for the image or continue reading, all without losing their current scroll position.
3In addition to media content, your website might be using widgets or third-party content that is added via JavaScript and that would also shift content if not handled carefully.
Although a lot of websites are responsive these days, most ads still have a fixed size. For a responsive website, we can use placeholders in our HTML, in which we load the predefined ads if they match the specified screen size.
/* On small screens show 320x250 banner */ @media all and (max-width: 500px) { .ad-container-s { width: 320px; height: 250px; } } /* On medium screens show 728x90 banner */ @media all and (min-width: 800px) { .ad-container-m { width: 728px; height: 90px; } } In our example, we have one medium rectangle (300 × 250) and one leaderboard (728 × 90). On small screens, we would show the rectangle, while on bigger screens we would show the leaderboard. By setting fixed dimensions for the placeholder, the loading of the ads won’t trigger a content shift.
5Many people will never see the ads, but only the empty placeholder, because they will be using an ad blocker, or the advertisement won’t show up for other reasons. Therefore, you should style the placeholder to indicate that there is normally an ad. If you are already using an ad-blocker detection script, you can replace the placeholder with a message or a promotion of your products7.
Users might even rethink the use of an ad blocker on your website if the ads have one less disadvantage — that distracting jump effect.
For other widgets, we might not know their exact sizes beforehand, but we can define the minimum heights the widgets will require.
.widget { min-height: 400px; } By using min-height, we will reserve enough space for most cases and avoid a big jump if the widget needs more space.
Finding the right size for min-height takes some time, but users will be thankful that their reading experience has not been abruptly interrupted.
Fonts have different x-heights. Therefore, our fallback font and web font will take up a different amount of space.
Currently, one best practice8 for loading web fonts is to use the Font Face Observer9 script to detect when a font has loaded so that it can be applied in the CSS afterwards.
In this example, we are applying the webfont-loaded class to the html element once the web font is ready to use.
var font = new FontFaceObserver('Lato'); font.load().then(function () { document.documentElement.className += " webfont-loaded"; }); In the CSS, we apply the web font once it has successfully loaded.
p {font-family: sans-serif;} .webfont-loaded p {font-family: 'Lato', sans-serif;} When the web font finally finishes loading, we will notice a quick jump. To minimize this, we can modify the x-height of the fallback font to match the web font as closely as possible, thus reducing the jump.
The font-size-adjust property10 allows you to specify the optimal aspect ratio for when a fallback font is used. For most fonts, the ratio is between 0.3 and 0.7.
To find the right aspect ratio for your web font, I recommend setting up your browser to show two paragraphs side by side, one with the web font and the other with the fallback font, and then adjust the property with your browser’s developer tools.
p { font-size-adjust: 0.5; } Because font-size-adjust is currently supported only11 in Firefox and Chrome (behind a flag), we can use a combination of letter-spacing and line-height to adjust the size of the fallback font in other browsers.
p { font-family: sans-serif; font-size: 18px; letter-spacing: 1px; line-height: 0.95; } /* Older browsers */ p { letter-spacing: 1px; line-height: 0.95; } /* If browser supports font-size-adjust, use this */ @supports (font-size-adjust: none) { p { letter-spacing: 0; line-height: 1; font-size-adjust: 0.59; } } /* Once the web font has loaded, apply this */ .webfont-loaded p { font-family: 'Lato', sans-serif; letter-spacing: 0; line-height: 1; } Here, we are defining letter-spacing and line-height as a fallback first, and we are using @supports12 to feature-detect and then apply font-size-adjust if it is supported.
We won’t get a perfect solution for all fonts, but it will minimize the distraction when the typeface changes.
Until now, we have covered media, widgets and fonts, but the content could also shift when the CSS for the main layout gets applied.
Flexbox can cause horizontal shifting13, as shown by Jake Archibald.
With flexbox, the content controls how the layout is displayed, whereas with grid layouts, the layout is displayed according to the grid definition. Therefore, using grid for the main layout is better.
You probably won’t see the content shift if you’re developing on a fast machine with a great Internet connection, but users who are surfing on a slow connection will.
.wrapper { display: flex; } .sidebar { flex: 1 1 30%; } .content { flex: 1 1 70%; } /* Use grid instead of flexbox if supported */ @supports (display: grid) { .wrapper { display: grid; grid-template-columns: 30% 70%; } .sidebar { grid-column: 1; } .content { grid-column: 2; } } Support14 for CSS grid layouts isn’t very good at the moment, but it will increase in the next month when Safari 10 ships, and Firefox and Blink-based browsers will probably enable it by default. To be future-proof, we should use flexbox as our foundation and enhance the experience with a grid layout if it is supported.
Changing CSS properties based on user interaction can often cause horizontal shifting. This can be avoided by using alternative CSS properties.
When changing the font weight of text, the size of the element will change and a content shift will occur.
a:hover, a:focus { font-weight: bold; } @supports (text-shadow: none) { a:hover, a:focus { font-weight: normal; text-shadow: 1px 0 0 currentColor; } } Redrawing text-shadow can be computationally more intensive than changing font-weight, but it is the only way to prevent the jump effect when changing to a heavier weight of text.
Once again, we are using feature-detection to apply text-shadow, instead of font-weight, upon interaction from the user. Because @supports is supported by fewer browsers than text-shadow, we could also consider using Modernizr15 to detect the feature and apply the improvement in all supported browsers.
Small details will often make a good experience great. Your users will appreciate every content shift that is avoided.
Now that you’ve learned about ways to avoid content jumps, you might be wondering why browsers can’t prevent content jumps more efficiently.
The Chrome team recently introduced scroll anchoring16, which does exactly that.
Scroll anchoring is a proposed intervention17 that adjusts the scroll position to reduce visible content jumps.
At the moment, scroll anchoring is only available behind an experimental flag in Chrome, but other browser vendors have shown interest and will hopefully implement it in future.
As you can see, there are many solutions for avoiding the jump effect on page load. Yes, implementing all of these techniques would take some time, but it is totally worth it — until scroll anchoring is supported in more browsers.
If you take the time to avoid jumps by using the techniques mentioned above — defining placeholders, reserving space and preparing for fallbacks — then users will have a less annoying experience and will be able to enjoy your content without interruption.
How do you minimize content shifting on your websites? Have you discovered any particular tricks or techniques to prevent the jump effect?
(il, al)
Front page image credits: Rayi Christian W.18
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
↑ Back to topTweet itShare on Facebook
In the last few years, I’ve seen a lot of code. As a freelancer working on multiple big projects with a lot of people, you’ll inevitably see all varieties of code styles. But I also realized how much writing JavaScript changed over the past years.
Having learned JavaScript before ES6 was there, a great mentor (Hans Christian Reinl1) taught me the most important lesson: Always write clean, understandable code. Avoid ternary operators, declare variables in one place, make functions as simple as possible. Basically things that so many JavaScript style guides also advise. But with the growing adoption of ES6/ES2015, I also saw an increase of code where most of these principles (except for keeping functions small) are ignored.
I think it has something to do with the increased flexibility of ES6. A lot of developers probably think since arrow functions — which are shorter than a normal function — can be used, they should also write everything else in the shortest, smartest way. However, in my opinion and experience, this leads to a less maintainable codebase, one that’s hard to read for people who don’t work on it on a daily basis. Be smarter! By applying simplicity and not cleverness to your code.
Clear-Site-Data8 and Feature-Policy9. They both improve the security and privacy of users. While the first one can clean locally-stored objects, the latter declares features the browser is allowed to use within the origin, such as geolocation, cookies, and WebRTC. As a site-owner, you can use this to prevent a third-party from tracking your users.target="_blank"11 on pages where users can add custom URLs. To make clear how bad the attack is, Ben Halpern now shows how he made it work on Instagram12 (they fixed it pretty fast). So remember to use rel="noopener" for any URL that you didn’t hard-code into the source.
13And with that, I’ll close for this week. If you like what I write each week, please support me with a donation26 or share this resource with other people. You can learn more about the costs of the project here27. It’s available via email, RSS and online.
— Anselm
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
↑ Back to topTweet itShare on Facebook
There is UI animation, and then there is good UI animation. Good animation makes you go “Wow!” — it’s smooth, beautiful and, most of all, natural, not blocky, rigid or robotic. If you frequent Dribbble or UpLabs1, you’ll know what I am talking about.
With so many amazing designers creating such beautiful animations, any developer would naturally want to recreate them in their own projects. Now, CSS does provide some presets for transition-timing-function6, such as ease-in, ease-out and ease-in-out, which add some level of smoothness and realism, but they are very generic, aren’t they? How boring would it be if every animation on the web followed the same three timing functions?
One of the properties of transition-timing-function is cubic-bezier(n1, n2, n3, n4), in which you can pass four numbers to create your very own timing function. Towards the end of this article, you’ll know exactly what these four numbers represent — still, believe me, coming up with four numbers to capture the transition you are imagining in your head is nowhere close to being easy. But thanks to cubic-bezier8 and Ceasar9, you don’t have to. These tools bring motion curves to the web.
Motion curves are primarily used by animators (for example, in Adobe After Effects11) to create advanced, realistic animations. With cubic-bezier and Ceasar, you can simply manipulate the shape of a curve, and those four numbers (n1, n2, n3, n4) will be filled in for you, which is absolutely great! Still, to use and make the most out of motion curves, you need to understand how they work, and that’s what we’re going to do in this article. Let’s begin.
A motion curve is nothing but a plot between any animatable property12 and time. A motion curve defines how the speed of an animation running under its influence varies over time.
Let’s take distance (translateX)15 as an example of an animatable property. (The explanation holds true for any other animatable property.)
16If you’ve had any experience with physics and basic calculus, you’ll know that deciphering speed from a distance-time graph is very simple. The first derivative of distance as a function of time, with respect to time, is speed, which means that an object following a distance-time curve would have greater speed in places where the curve is steep and lower in places where the curve is flatter. If you know how that works, great! You’re all set and can skip to the next section.
Now, I am aware that design and development is a diverse field, and not everyone has the same background. Perhaps the two paragraphs above were all jargon to you. Don’t fret. We’ll keep going and make sense of the jargon.
Consider the red box below. Let’s get a little callow here and call the red box “Boxy”; it’ll be easier to refer to it that way. All right, so Boxy is going to move from one edge of the screen to the other in a linear fashion, and we are going to analyze its motion.
One of the presets of transition-timing-function is linear. To make Boxy move, all we do is add the following class.
.moveForward { transform: translateX(1000px); } To control the animation, we would set the transition property for Boxy as follows:
#boxy { width: 200px; height: 200px; background: red; transition-property: transform; transition-duration: 1s; transition-timing-function: linear; }That’s a very verbose way to specify transition. In reality, you will almost always find transition written in its shorthand form:
#boxy { width: 200px; height: 200px; background: red; transition: transform 1s linear; }Let’s see it go.
18Robotic, isn’t it? You could say that this motion feels robotic because it’s linear, which is a perfectly plausible answer. But could you explain why? We can see that setting linear results in robotic motion, but what exactly is happening behind the scene? That’s what we’ll figure out first; we’re going to get to the innards and understand why this motion feels robotic, blocky and not natural.
Let’s start by graphing Boxy’s motion to see if we can gain some insight. Our graph will have two axes, the first being distance, and the second time. Boxy covers a total distance of 1000 pixels (distance) in 1 second (time). Now, don’t get scared by all the math below — it’s very simple.
Here is our very simple graph, with the axes as mentioned.
19Right now, it’s empty. Let’s fill it up with some data.
To start off with, we know that at 0 seconds, when the animation has not yet started, Boxy is in its initial position (0 pixels). And after 1 second has passed, Boxy has travelled a total of 1000 pixels, landing at the opposite edge of the display.
21Let’s plot this data on the graph.
23So far so good. But two data points are not enough — we need more. The following figure shows the positions of Boxy at different points of time (all thanks to my high-speed camera).
25Let’s add this data to our graph.
27You could, of course, have many more data points for different times (for example, 0.375 seconds, 0.6 seconds, etc.) but what we have is enough to complete our graph. By joining all of the points, we have completed the graph. High five!
29Cool, but what does this tell us? Remember that we started our investigation with the goal of understanding why Boxy’s linear motion feels unnatural and robotic? At a glance, this graph we’ve just constructed doesn’t tell us anything about that. We need to go deeper.
Keep the graph in mind and let’s talk for a minute about speed. I know you know what speed is — I’d just like to put it in mathematical terms. As it goes, the formula for speed is this:
31Therefore, if a car covers a distance of 100 kilometers in 1 hour, we say its speed is 100 kilometers per hour.
33If the car doubles its speed, it will start covering double the distance (200 kilometers) in the same interval (1 hour), or, in other words, it will cover the original distance of 100 kilometers in half the time (0.5 hours). Make sense?
Similarly, if the car halved its speed (that is, slowed down by half), it would start covering a distance of 50 kilometers in the same interval (1 hour), or, in other words, it would cover the original distance of 100 kilometers in twice the time (2 hours).
Great! With that out of the way, let’s pick up where we left off. We were trying to figure out how the graph between distance and time can help us understand why Boxy’s linear motion feels robotic.
Hey, wait a second! We have a graph between distance and time, and speed can be calculated from distance and time, can’t it? Let’s try to calculate Boxy’s speed at different time intervals.
35Here, I’ve chosen three different time intervals: one near the start, one in the middle and one at the end near the final position. As is evident, at all three intervals, Boxy has exactly the same speed (s1 = s2 = s3) of 1000 pixels per second; that is, no matter what interval you choose in the graph above, you will find Boxy moving at 1000 pixels per second. Isn’t that odd? Things in real life don’t move at a constant speed; they start out slowly, gradually increase their speed, move for a while, and then slow down again before stopping, but Boxy abruptly starts with a speed of 1000 pixels per second, moving with the same speed and abruptly stopping at exactly the same speed. This is why Boxy’s movement feels robotic and unnatural. We are going to have to change our graph to fix this. But before diving in, we’ll need to know how changes to the speed will affect the graph drawn between distance and time. Ready? This is going to be fun.
Let’s double Boxy’s speed and see how the appearance of the graph changes in response. Boxy’s original speed, as we calculated above, is 1000 pixels per second. Because we have doubled the speed, Boxy will now be able to cover the distance of 1000 pixels in half the time — that is, in 0.5 seconds. Let’s put that on a graph.
37What if we tripled the speed? Boxy now covers 1000 pixels in one third of the time (a third of a second).
39Hmm, notice something? Notice how, when the graph changes, the angle that the line makes with the time axis increases as the speed increases.
All right, let’s go ahead and halve Boxy’s speed. Halving its speed means that Boxy will be able to cover only 500 pixels (half the original distance) in 1 second. Let’s put this on a graph.
41Let’s slow down Boxy a little more, making the speed one third of the original. Boxy will be able to cover one third of the original distance in 1 second.
43See a pattern? The line gets steeper and steeper as we increase Boxy’s speed, and starts to flatten out as we slow Boxy down.
45This makes sense because, for a steeper line, a little progress in time produces a much higher change in distance, implying greater speed.
47
49On the other hand, for a line that is less steep, a large change in time produces only a little change in distance, meaning a lower speed.
51
53With all of the changes we have made, Boxy is still moving in a linear fashion, just at different speeds. However, with our newly gained knowledge of how changes to distance versus time can affect speed, we can experiment and draw a graph that makes Boxy move in a way that looks natural and realistic.
Let’s take it step by step. First, things in real life start out slow and slowly increase in speed. So, let’s do that.
In all of the iterations of the graph shown below, you will notice that the points at opposite corners remain fixed. This is because we are not changing the duration for which the animation runs, nor are we changing the distance that Boxy travels.
55If Boxy is to follow the graph above, it will move at a slower speed for 0.25 seconds, because the line is less steep starting from 0 to 0.25 seconds, and then it will abruptly switch to a higher speed after 0.25 seconds (the reason being that the line in the graph gets steeper after 0.25 seconds). We will need to smoothen this transition, though; we don’t want any corners — it’s called a motion curve, after all. Let’s convert that corner to a curve.
57Notice the smooth transition that Boxy undergoes from being at rest to gradually increasing in speed.
59Good! Next, objects in real life progressively slow down before stopping. Let’s change the graph to make that happen. Again, we’ll pick up a point in time after which we would like Boxy to start slowing down. How about around 0.6 seconds? I have smoothened out the transition’s corner to a curve here already.
61Look at Boxy go! A lot more natural, isn’t it?
63The curve we drew in place of the corner is actually a collection of many small line segments; and, as you already know, the steeper the line on the graph, the higher the speed, and the flatter the line, the slower the speed. Notice how in the left part of the image, the line segments that make up the curve get steeper and steeper, resulting in a gradual increase in speed, and progressively flatten out on the right side, resulting in the speed progressively decreasing?
65With all of this knowledge, making sense of motion curves becomes much easier. Let’s look at a few examples.
67
69
71
73
75
77The next time you have to animate a UI element, you will have the power of motion curves at your disposal. Whether it’s a slide-out bar, a modal window or a dropdown menu, adding the right amount of animation and making it look smooth and natural will increase the quality of your user interface greatly. It will make the user interface just feel good. Take the slide-out menu below:
See the Pen nJial80 by Nash Vail (@nashvail9681) on CodePen9782.
Clicking on the hamburger menu brings in the menu from left, but the animation feels blocky. Line 51 of the CSS shows that the animation has transition-timing-function set to linear. We can improve this. Let’s head on over to cubic-bezier9183 and create a custom timing function.
If you’re reading this, it’s safe to assume that you’re a designer or a developer or both and, hence, no stranger to cubic bezier curves; there’s a good chance you’ve encountered them at least once. Bezier curves are a marvel. They are used primarily in computer graphics to draw shapes and are used in tools such as Sketch84 and Adobe Illustrator85 to draw vector graphics. The reason why cubic bezier curves are so popular is that they are so easy to use: Just modify the positions of the four different points, and create the kind of curve you need.
Because we always know the initial and final states of the animated object, we can fix two of the points. That leaves just two points whose positions we have to modify. The two fixed points are called anchor points, and the remaning two are control points.
86As you remember, cubic-bezier accepts four numbers (n1, n2, n3, n4) when you create a custom transition-timing-function. These four numbers represent nothing but the positions of the two control points: n1, n2 represents the x and y coordinates of the first control point, and n3, n4 represents the coordinates of the second control point. Because changing the position of the control points will change the shape of the curve and, hence, our animation overall, the result is the same when any or all of n1, n2, n3, n4 is modified. For example, the figure below represents cubic-bezier(.14, .78, .89, .35):
88(.14, .78, .89, .35) (View large version89)The math behind these seemingly simple curves90 is fascinating.
All right, all right, let’s get back to where we were going with cubic-bezier9183: creating a custom transition-timing-function. I want the kind of animation in which the menu slides in very quickly and then gracefully slows down and ends:
This looks good. The animation will start out fast and then slow down, rather than move at a constant speed throughout. I am simply going to copy cubic-bezier(.05, .69, .14, 1) from the top of the page and replace linear with it.
See the Pen nJial95 by Nash Vail (@nashvail9681) on CodePen9782.
See the difference? The second iteration feels much more natural and appealing. Imagine if every animation in your UI followed a natural timing function. How great would that be?
As we’ve seen, motion curves aren’t tricky at all. They are very easy to understand and use. With them, you can take your UI to the next level.
I hope you’ve learned how motion curves work. If you were going through a lot of trial and error to get motion curves to work the way you want, or if you were not using them at all, you should now be comfortable bending them to your will and creating beautiful animations. Because, after all, animation matters.
(al)
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
↑ Back to topTweet itShare on Facebook
Due to an increased emphasis on website security in today’s digital landscape, one of the most common requests we’ve gotten from readers is to do a pros and cons analysis of Sucuri vs CloudFlare to explain which one is better. Sucuri and CloudFlare are online services that offer website firewall, CDN, and DDoS protection services. In this article, we will compare Sucuri vs Cloudflare with pros and cons to find out which one is better.
Even the most secure websites on the internet are vulnerable to distributed denial of service attacks (DDoS), hacking attempts, and malware injection.
As a WordPress site owner you can use some security best practices like password protecting admin directory, limiting login attempts, adding two factor authentication, etc.
However these tips only work on software level which leaves your website mostly open to other types of attacks. These attacks can cause financial damage, data loss, poor search rankings and bad user experience.
Sucuri and CloudFlare offer a website application firewall (WAF).
This means that all your website’s traffic goes through their server scanners. If a request looks malicious, then the firewall would block it before it even reaches your website.
On the surface, these two services look nearly identical, but there are some key differences.
In this comparison, we’ll focus on:
By the end, you’ll know exactly which platform is best for you.
Ready? Let’s compare Sucuri vs Cloudflare.
In this section, we will look at the features offered by Sucuri and CloudFlare.
It’s important to note that both services offer different plans that come with different set of features.
As a user, make sure you’re not a victim of their marketing site because not all plans come with all the features.
CloudFlare is best known for their free CDN service. They specialize in mitigating DDOS attacks using their Website Application Firewall product. CloudFlare keep your site available to users during an attack or under heavy traffic when your server is not responsive.
Their website firewall blocks suspicious traffic before it even reaches your website. The firewall also extends to form submissions which protects your website from comment spam and registration spam.
CloudFlare also offers free and custom SSL certificates with all their plans. Free and pro plans only allow you to use CloudFlare issued certificate. For custom certificate you will need to upgrade to their Business or Enterprise plan.
While CloudFlare offer a free option that includes CDN, most other features including their Website Application Firewall require a paid plan.
CloudFlare doesn’t offer server scanning service to detect malware. It also doesn’t offer a malware removal guarantee if you were to be hacked on their watch.
Sucuri is one of the most reputable website security and monitoring service. They offer comprehensive website monitoring, scanning for malware, DDoS protection, and malware removal services.
Sucuri offers CloudProxy, a website firewall and load balancing service. It blocks suspicious traffic from reaching your website by effectively blocking DDoS attacks, code injection, bad bots, and other website threats. See our case study of how Sucuri helped us block 450,000 attacks in 3 months.
Sucuri offers integration with the free Let’s Encrypt SSL for their basic plan. You can also use custom SSL certificates with their professional and business plans.
Sucuri scans your website regularly for file changes, code injection, and malware. They clean up hacked sites, with support for all popular CMS software like WordPress, Joomla, Drupal, etc.
Winner: Sucuri is a clear winner because they offer a better combination of tools and services (Website Firewall + Load Balancing + Malware Cleanup / Hack Repair).
Pricing is an important factor for many small businesses.
Here, we will compare the different pricing plans offered by CloudFlare and Sucuri, so you know exactly what you’re getting for your money.
FREE is not always better
CloudFlare offers a free CDN service for all. They don’t charge you for the bandwidth which means you will be able to use their free CDN regardless of your traffic volume.
However, this free plan does not come with the website application firewall. Your website may benefit from CDN, but it will not be properly protected against DDoS attacks, spam, bad traffic, etc.
For their web application firewall, you need the Pro plan which costs $20 / month (this is what you need for improved security).
This pro plan does not include advanced DDoS mitigation and custom SSL. For those features, you will need their Business plan which costs $200 per month.
Unlike CloudFlare, Sucuri doesn’t offer a free plan. Their website security stack plan starts at $199.99 for an year, which is cheaper than CloudFlare’s pro plan.
This basic plan includes full website monitoring, website application firewall, DDoS protection, malware removal, and free LetsEncrypt SSL certificate.
Instead of excluding features from lower level plans, Sucuri uses priority as an incentive for their higher paying plans.
For example, malware removal estimated time for basic plan is 12 hours, 6 hours for professional plan, and 4 hours for business plan. However, the actual cleanup timings are way faster than that for all customers.
They offer 24/7 support as part of all plans. Their business plan subscribers can also use the Live Chat support.
Winner:Sucuri is an obvious choice for small businesses when it comes to pricing. CloudFlare Pro costs $240 / year vs Sucuri cost $199 / year and offer more features. To unlock same features, you’d have move up to CloudFlare’s $2400 / year plan. Sucuri’s most expensive plan is at $499 / year.
Apart from denial of service attacks, malware and code injections are the most common threats faced by WordPress site owners.
Let’s see how both services protect your website against those common threats.
CloudFlare free version is basically a content delivery network which helps make your website fast.
The website security firewall comes with their paid plan. It includes CloudFlare’s ready to use custom rules set. These rules protect your site from common code injection hacks, XSS JavaScript exploits, and form submissions.
However, they do not offer file change detection, malware scanning, blacklist monitoring, and many other security features. You can add third-party apps for malware scanning, but these services will cost you additional fees.
Sucuri is a security focused company. They specialize in monitoring websites and protecting them against malware and other attacks.
Sucuri’s website application firewall protects you against DDOS, SQL injections, XSS JavaScript injections, comment and contact form spam.
However, if something crosses all those security barriers and somehow reaches your website, then Sucuri offers to clean up your website (for free).
If you already have a website affected with malware, then Sucuri will clean that up as well.
Winner:Sucuri – For combining website application firewall with monitoring, malware protection, and clean up services.
CloudFlare and Sucuri both offer protection against DDoS attacks on your website. CloudFlare does a little better in the content delivery network area.
Sucuri fares better in the overall features, better security monitoring, and lower prices. If you are using a CMS like WordPress, then Sucuri is what you need.
We hope this article helped you compare pros and cons of Sucuri vs CloudFlare. You may also want to see our list of 7 best WordPress backup plugins.
If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.
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.
Mobile is more important than ever6. But getting an app just right, getting it to work across all possible devices, with different OS versions, display resolutions, chipsets and other hardware characteristics, and making the user experience smooth across all possible configurations, is a challenging task.
A ton of great technologies, tools, frameworks and open-source components are available for building native mobile apps. What value does React Native9 bring to the scene, and how can we make sure that apps built with it are well received by their target audiences?
In this article, we’ll look at what’s available for testing React Native apps10. First, I’ll explain some key features of React Native, before looking at how to implement these tests. Secondly, I’ll categorize testing methods and frameworks on three levels (unit, integration, functional), providing examples for each. Finally, I’ll provide simple examples of how to implement tests using the most popular open-source test-automation frameworks for functional app testing.
It all got started with React11 more than three years ago, when Facebook introduced its framework to web developers. It was bound to be popular, not just because it was authored and developed by Facebook, but because of the capabilities it provided to web developers — and especially how it changed the way we build apps.
The concept of this type of “learn once, write anywhere” framework wasn’t new, though; we had already seen JavaScript libraries do similar things (Sencha12, PhoneGap13 and Appcelerator14, among others), but something was better about React that had an impact on developers’ habits and how they break down an application’s UI into discrete components.
React Native does not use the DOM for rendering. Instead, it renders with native UI views, which means you are using the native components provided by the operating system. This sort of product-creation flow, where you replace the DOM API with a more declarative API, gives developers a more cohesive and simplified level of abstraction15.
16The key thing about React Native is that it brings the React programming model19 to mobile apps, development and testing. It doesn’t actually work directly as a cross-platform tool or framework, but it accelerates the trend of building mobile apps on this new platform. And that’s one of the cornerstones of what makes React Native so powerful, easy to learn and easy to write on this new platform.
The major difference, as well as advantage, of native mobile versus the web is that, instead of running a JavaScript-based implementation in a browser and exposing HTML elements, we are now relying on the embedded JavaScriptCore in apps20, which get platform-specific UI elements.
All mobile software is built using composition. On Android and iOS21, this means that small software components are arranged together to form larger, higher-level components with greater functionality, until the goals and requirements of the application have been met. A good testing practice is to run tests that cover functionality at all levels of the composition.
In this article, I’ll cover test methods and automation frameworks at three levels. The primary focus is on the highest level, functional testing, but React Native apps can be tested — and testing can be automated — on at least the following levels:
In addition to ReactTestUtils2322, React Native provides useful unit-testing methods24, but none of them thoroughly cover the application’s actual logic. Therefore, mobile apps built on React Native benefit more from functional UI testing. A variety of functional test-automation frameworks25 are available, and we’ll look at few of the most popular ones in this article.
While unit testing can be done at the component level, functional test automation provides better capabilities for testing the larger entities in a React Native app. With React Native, component logic unit testing can be done in isolation, using traditional JavaScript libraries and forcing React Native to return regular components instead of native ones. With functional test-automation frameworks, UI components are part of the app and are easy to test as a whole.
I’ll separate these frameworks into cross-platform frameworks26 and platform-specific frameworks4027, as illustrated in the picture below.
28The best part of React Native apps is that they are fully native for both major mobile platforms (Android and iOS). This means we get more frameworks, tools and native methods for testing purposes. We’ll look at functional test-automation frameworks in the section below titled “Using Functional Test-Automation Frameworks With React Native Apps31.”
Let’s start with unit-testing capabilities32, using a JavaScript test to illustrate.
By default, React Native provides Jest33 tests for unit testing, and this works for both Android and iOS. Currently, test coverage isn’t perfect, but according to Facebook, more unit-testing capabilities will be introduced in React Native, and users can already build their own.
Jest uses the Jasmine behavior-driven framework34 as the basis for testing JavaScript code. Every test case starts from a describe() function call, similar to how JUnit uses the TestCase class. The describe() function takes two parameters: the description and title of the test case, and the function to be executed. The it() function includes all of the test steps and (similar to JUnit) provides a series of expect() functions.
Here is an example of a Jasmine test script for a player application.
describe("Player", function() { var player; var song; beforeEach(function() { player = new Player(); song = new Song(); }); it("should be able to play a song", function() { player.play(song); expect(player.currentlyPlayingSong).toEqual(song); //demonstrates use of custom matcher expect(player).toBePlaying(song); }); describe("when song has been paused", function() { beforeEach(function() { player.play(song); player.pause(); }); it("should indicate the song is paused", function() { expect(player.isPlaying).toBeFalsy(); // demonstrates use of 'not' with a custom matcher expect(player).not.toBePlaying(song); }); it("should be possible to resume", function() { player.resume(); expect(player.isPlaying).toBeTruthy(); expect(player.currentlyPlayingSong).toEqual(song); }); }); // demonstrates use of spies to intercept and test method calls it("tells the current song whether the user has made it a favorite", function() { spyOn(song, 'persistFavoriteStatus'); player.play(song); player.makeFavorite(); expect(song.persistFavoriteStatus).toHaveBeenCalledWith(true); }); //demonstrates use of expected exceptions describe("#resume", function() { it("should throw an exception if song is already playing", function() { player.play(song); expect(function() { player.resume(); }).toThrow("song is already playing"); }); }); });This basic example shows how Jasmine can be used to test the functionality of an app, but it keeps the focus on method-level testing. In addition, React Native provides some basic capabilities for testing integrated components. This works for both native and JavaScript components and enables communication between them via a bridge.
At the moment, integration tests highlighted in the React Native community are available only for iOS and are very limited in their ability to test components. The communication goes through the bridge and requires both native and JavaScript components. For this functionality, two components are available to implement customized integration tests, RCTestRunner35 and RCTestModule36.
A basic Objective-C example for building a test skeleton of an iOS app would start like this:
@implementation ExampleTests { RCTTestRunner *_runner; } - (void)setUp { [super setUp]; _runner = RCTInitRunnerForApp(@"IntegrationTestHarnessTest", nil); } - void()testExampleTests { [_runner runTest:_cmd module:@"ExampleTests"] } @endHowever, there are other ways to run integration testing and to extend it to Android and iOS. A good alternative for running both unit and integration tests is Mocha37, which provides a feature-rich JavaScript test framework that runs on Node.js38. Mocha also provides behavior-driven development (BDD), test-driven development (TDD) and QUnit interfaces for testing.
For functional UI testing, I’ll be covering the most prominent and most used test-automation frameworks, including Appium, Calabash, XCTest and a few others.
To streamline the app development process and to maximize testing coverage, we have numerous open-source test-automation frameworks to choose from.
The best choice — if your app will run on several OS platforms — is a framework that supports multiple platforms39 and provides a robust foundation for test automation. In mobile, the term “cross-platform” refers to a framework that provides the same API, tools and capabilities for both Android and iOS.
In addition, a range of great platform-specific frameworks4027 are available. Naturally, each framework has been built for a particular platform and, in most cases, is easier to adopt for that platform. In addition to Appium and Calabash, I’ll cover four platform-specific frameworks in this article: Robotium and Espresso for Android, and XCTest and EarlGrey for iOS.
41When it comes to test automation, bear in mind that apps built with React Native are fully native on both iOS and Android; hence, functional test-automation frameworks will work fine with them.
The example I’ll use with each framework is an implementation of a very basic radio button UI.
<Radio onSelect={this.onSelect.bind(this)} defaultSelect={this.state.optionSelected - 1}> <Option color="black" selectedColor="#000000"> <Item title="First option" description="First radio button"/> </Option> <Option color="black" selectedColor="#000000"> <Item title="Second option" description="Second radio button"/> </Option> <Option color="black" selectedColor="#000000"> <Item title="Third option" description="Third radio button"/> </Option> </Radio> The test snippet included in each framework section below shows how the test script deals with each UI element and how clicks and other user inputs are handled. The purpose of the examples is not to provide step-by-step instructions, but rather to compare examples and show what is available for test automation today and what programming languages can be used for testing.
As stated, React Native is not actually a cross-platform framework, but adoption of it across other platforms is easy. In the next two sections, we’ll go through two popular cross-platform test-automation frameworks for mobile testing and mobile test automation.
Appium44 is an open-source test-automation framework, with an inspection tool that works well for native, hybrid and mobile web apps. It uses JSONWireProtocol45 internally to interact with iOS and Android apps, using Selenium WebDriver46. Because of this, Appium works extremely well for the mobile web as well, and the use cases are very similar if Selenium is used for web testing.
In fact, Appium has been a rising star in mobile test automation47 in the last year. Originally, it was built to provide cross-platform support for both major platforms, Android and iOS.
Being cross-platform means that the framework and its scripts work exactly the same on both platforms. In addition, Appium provides fantastic programming language support48 — developers can write tests using their favorite language (for example, Java, Ruby, Python, C#), tools and environment. It’s also easy to get started, to create and maintain reusable tests, and to execute those tests on real physical devices.
When it comes React Native-powered apps, JavaScript isn’t necessarily required; tests can be written in any language. For example, Appium scripts can look like this:
driver.findElement(By.id("com.example.app:id/radio0")).click(); driver.findElement(By.id("com.example.app:id/radio1")).click(); driver.findElement(By.id("com.example.app:id/radio2")).click(); driver.findElement(By.id("com.example.app:id/editText1")).click(); driver.findElement(By.id("com.example.app:id/editText1")).sendKeys("Simple Test"); driver.findElement(By.name("Answer")).click(); // or alternatively like this: driver.findElement(By.id("com.example.app:id/button1")).click();So, how do these WebDriver functions access apps running on devices? Basically, Appium starts a test script on the device or emulator, which then creates a server and listens for commands from the main Appium server. It is the same as the Selenium server, which gets HTTP requests from Selenium client libraries49. The difference between Android and iOS is illustrated in the picture below:
50With iOS, Selenium WebDriver gets a command from the Appium script (for example, click()) and sends it in the form of JSON via an HTTP request to the Appium server53. Appium knows the automation context and sends this command to the Instruments command server, which waits for the Instruments command client to pick it up and execute it with bootstrap.js in the iOS Instruments environment. Once the command is executed, the Instruments command client sends the message back to the Appium server, which logs everything related to the command in its console. This cycle keeps going until the test script has finished.
On Android, things work almost the same way, except that the frameworks used are Selendroid and UiAutomator54. In short, Appium translates WebDriver commands to UiAutomator (API level 17 or higher) or Selendroid (API level 16 or lower) commands. On a physical device, bootstrap.jar launches a TCP server that gets commands from a TCP client. The process is similar on iOS.
If you are interested in getting started with Appium, plenty of material is available, including step-by-step instructions55 and Appium tutorials56.
Another great cross-platform testing framework is Calabash57, which enables anyone to write tests for mobile applications. The main difference is that Calabash tests are written in Cucumber58. The idea behind using this sort of language for tests is awesome: The test itself is like a specification, and all tests are simple and easy to read yet executable by the automation system.
Compared to Appium, Calabash provides an easier way to create cross-platform tests for Android and iOS. This is due to the straightforward vocabulary and specification-oriented language, which makes Calabash tests identical on both platforms. The actual tests are written in Gherkin59 and run in Cucumber.
Because of these capabilities, the differences between Calabash working on Android60 and on iOS61 applications are minor. Again, there is no implication for React Native apps because all components and user interfaces are fully native to these platforms.
62The basic testing and test-creation flow, however, remains the same. Calabash (and Gherkin) tests comprise features, scenarios and steps. The recommended approach is to complete the highest-level descriptions first: features, followed by scenarios and then the actual steps. A good rule of thumb is to create Calabash features65 first.
66The example below shows how our application and its UI components (radio buttons, text field and button) would be implemented in Calabash:
Feature: Answer the question feature Scenario: As a valid user, I want to answer app question, I wait for text "What is the best way to test application on a hundred devices?" Then I press radio button 0 Then I press radio button 1 Then I press radio button 2 Then I enter text "Simple Test" into field with id "editText1" Then I press view with id "Button1"Steps usually begin with one of the keywords given, then, when, and or but. However, they don’t have to; they can use * instead.
Calabash is also widely used by non-developers, and it can be used for product specifications and documentation due to its easy-to-understand language and logic. Eventually, the features and scenarios are wrapped in Ruby code.
Setting up Calabash69 and starting to work with it are easy. If you have Bundler70 and Ruby (or rbenv) installed, just hit these few lines in your console, and a Calabash environment will soon be set up:
$ gem install calabash-android $ gem install calabash-cucumberThis will take care of installing Calabash-Android and Calabash-iOS, and your journey with test automation can begin.
When it comes to automating tests on Android and iOS apps, there are certain advantages to using platform-specific frameworks over cross-platform ones. For instance, some frameworks are built closely to SDKs and IDEs71, which are readily available while an application is under development. Let’s look at a few examples of these types of frameworks for Android and iOS.
Robotium72 was one of the first testing frameworks to work for native and hybrid Android apps. The UI tests created with Robotium enable functional, system and user-acceptance tests for Android apps, spanning and handling multiple Android activities. In fact, Robotium provides support for very early versions of Android, starting from API level 8.
Recently, Robotium was extended with the ExtSolo library73, which provides various useful features for app testing:
With Java code, tests are easy to build using any Java SDK and IDE. The primary function used in this example is findViewById, which finds a view that is identified by the id attribute. The UI element could be also identified by a name, class or some other attribute. Our code example with an id attribute would look like this:
solo.clickOnView(solo.findViewById("com.example.app:id/radio0")); solo.clickOnView(solo.findViewById("com.example.app:id/radio1")); solo.clickOnView(solo.findViewById("com.example.app:id/radio2")); solo.enterText((EditText) solo.findViewById("com.example.app:id/editText1"), "Simple Test"); solo.clickOnView(solo.findViewById("com.example.app:id/button1"));Robotium here is trying to locate UI elements based on the id, description and other characteristics. Unfortunately, this isn’t always the best approach and does not necessarily work well with webview components. However, with the help of the ExtSolo library, users can define clicks and other interactions on UI elements that scale with the resolution. Also, hardcoding coordinates is possible, and these scale when the display resolution changes.
If you are using Robotium, then getting started with Robotium ExtSolo is easy and effortless. Just clone the repository for yourself and build the library:
$ git clone https://github.com/bitbar/robotium-extensions $ ant clean instrumentAfter this, place the recently built .jar file in the libs folder in your Android Studio project, and make sure your project is linked to it. All of these great additional features and services are now in your workspace.
The Espresso74 testing framework provides APIs for writing UI tests to simulate user interactions for an Android app. The Espresso API75 is lightweight and provides three main components: viewMatchers, viewActions and viewAssertions.
The beauty of Espresso is that it provides automatic synchronization of test methods and UI elements that are being tested. For example, if the test script wants to press a button but the button isn’t visible on the screen yet, it will wait until this button can be pressed (i.e. it is visible and a click can happen). This makes test execution very fast because no test scripts need to include any sleep or wait commands. Also, developers do not need additional logic to handle timing-related issues.
// R class ID identifier for radio buttons onView(withId(R.id.radio0)).perform(click()); onView(withId(R.id.radio1)).perform(click()); onView(withId(R.id.radio2)).perform(click()); onView(withId(R.id.EditText1)).perform(click()); // Instead of R, we use getIdentifier onView(withId(getInstrumentation().getTargetContext().getResources() .getIdentifier("com.example.app:id/EditText1", null, null))).perform((typeText("Simple Test"))); onView(withId(getInstrumentation().getTargetContext().getResources() .getIdentifier("com.example.app:id/Button1", null, null))).perform(click());Espresso has its own pros and cons, and due to the lightweight API, not many additional services or function calls are available to developers. For instance, you must use alternative methods to take screenshots, manage tests, output test results and more.
At Google IO 201676 Google introduced Espresso Test Recorder as an integral part of Android Studio. While the feature is not yet available, it will definitely be worth the wait.
XCTest77 is tightly coupled with Xcode but is still usable with both real iOS devices and simulators. XCTest allows developers to write tests for components at any level and also provides a framework for UI testing capabilities. XCTest tests are grouped into subclasses of XCTestCase78. Writing any tests with XCTest should be trivial to iOS developers because XCTest is fully compatible with both Objective-C and Swift.
KIF79 (short for “keep it functional”) is an iOS integration test framework that is closely related to and that uses XCTest test targets. KIF tests can be executed directly in XCTestCase or any subclass. KIF allows for easy automation of iOS applications by leveraging the accessibility attributes that the OS makes available to those with visual disabilities.
Let’s see how our UI components would look with Objective-C:
- (void)testClicksOnRadioButtons { [tester tapViewWithAccessibilityLabel:@”Radio1”]; [tester tapViewWithAccessibilityLabel:@”Radio2”]; [tester tapViewWithAccessibilityLabel:@”Radio3”]; [tester enterText:@”Simple Test” intoViewWithAccessibilityLabel:@”editText1”]; [tester tapViewWithAccessibilityLabel:@”Answer”]; }Alternatively, with Swift, the test would look as simple as this:
testClicksOnRadioButtons() { let app = XCUIApplication() app.radiobutton[0].tap() app.radiobutton[1].tap() app.radiobutton[2].tap() app.staticTexts[“Simple Test”] app.button[0].tap() }Note that this high-level pseudo-code requires additional code in order to fully function. If you are looking for more information on XCTest and generally on using Xcode testing capabilities, Apple has you covered80.
It was just earlier this year when Google open-sourced81 its functional iOS app-testing framework, named EarlGrey. Being used internally by Google, it has worked relatively well with native iOS apps — YouTube, Google Calendar, Google Photos, Google Play Music, to name a few — and has sparked some serious interest. To get started with EarlGrey82, you’ll need the Xcode environment installed and basic knowledge of iOS development.
There are a lot of similarities between EarlGrey and Espresso (yes, both are developed by Google), and their characteristics make both frameworks work and execute tests quickly. Similar to Espresso, EarlGrey tests automatically wait for events (animations, network requests, etc.) before trying to interact with the UI. This makes writing tests easier because developers do not need to worry about sleep or wait commands. In addition, the code itself is easier to maintain because it provides procedural descriptions of the test steps.
EarlGrey also contains matchers that are available from the GREYMatchers83 class. The documentation recommends using UI elements with the accessibility parameters. To identify UI elements, developers can use grey_accessibilityID() or grey_accessibilityLabel().
- (void)testBasicSelectionAndAction { [[EarlGrey selectElementWithMatcher::grey_accessibilityID(@"ClickHere")] performAction:grey_tap()]; // Example of long press with EarlGrey matchers - (void)testLongPress { [[EarlGrey selectElementWithMatcher::grey_accessibilityLabel(@"Box")] performAction:grey_longPressWithDuration(0.5f)]; [[EarlGrey selectElementWithMatcher::grey_accessibilityLabel(@"One Long Press")] assertWithMatcher:grey_sufficientlyVisible()]; // Example of multi-select, visible click on items - (void)testCollectionMatchers { id visibleSendButtonMatcher = grey_allOf(grey_accessibilityID(@"Box"), grey_sufficientlyVisible(), nil); [[EarlGrey selectElementWithMatcher:visibleSendButtonMatcher] performAction:grey_tap()]; }Similar to XCTest, our radio button implementation isn’t that straightforward, and buttons for XCTest should be defined as iOS-supported UIElements to enable clicks and user interactions.
We’ve covered the basics of React Native applications and how they can be tested using various methods and frameworks. This comes up quite often, but the industry standards for mobile test automation at the functional UI level will work on React Native apps just as they do with any other native apps. The test-automation frameworks we’ve covered here are widely used for native mobile apps, hybrid apps, the mobile web as well as React Native apps.
In summary, determining the programming language that a mobile application is built on is not critical because it won’t have any influence on the test-automation frameworks that it can be tested with. As discussed, plenty of powerful test-automation frameworks are available today, which React Native apps will work with when wrapped as an APK or IPA.
What are you using for React Native app testing? Weigh in with a comment below!
(al, ml)
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
↑ Back to topTweet itShare on Facebook
Recently, one of our readers asked if it’s possible to delay posts from appearing in the WordPress RSS feed? Delaying posts in your RSS feed can save you from accidental publishing and beat content scrapers in SEO. In this article, we will show you how to delay post from appearing in WordPress RSS feed.
Sometimes you may end up with a grammar or spelling mistake in your article. The mistake goes live and is distributed to your RSS feed subscribers. If you have email subscriptions on your WordPress blog, then those subscribers will get it as well.
By adding a delay between your RSS feed and your live site, you get a little time window to catch an error on a live site and fix it.
RSS feeds are also used by content scraping websites. They use it to monitor your content and copy your posts as soon as they appear live.
If you have a new website with little authority, then a lot of times these content scrapers may end up beating you in the search results.
By delaying an article in the feed, you can give search engines enough time to crawl and index your content first.
Having said that, let’s see how to easily delay posts from appearing in WordPress RSS feed.
This method requires you to add little code into WordPress. If this is your first time adding code manually, then take a look at our beginner’s guide on pasting snippets from web into WordPress.
You need to add the following code to your theme’s functions.php file or in a site-specific plugin.
function publish_later_on_feed($where) { global $wpdb; if ( is_feed() ) { // timestamp in WP-format $now = gmdate('Y-m-d H:i:s'); // value for wait; + device $wait = '10'; // integer // http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html#function_timestampdiff $device = 'MINUTE'; //MINUTE, HOUR, DAY, WEEK, MONTH, YEAR // add SQL-sytax to default $where $where .= " AND TIMESTAMPDIFF($device, $wpdb->posts.post_date_gmt, '$now') > $wait "; } return $where; } add_filter('posts_where', 'publish_later_on_feed');
This code checks to see if a WordPress feed is requested. After that it sets the current time and the time you want to add as delay between post’s original date and the current time.
After that it adds the timestamp difference as the WHERE clause to the original query. The original query will now only return the posts where timestamp difference is greater than the wait time.
In this code we have used 10 minutes as $wait or delay time. Feel free to change that into any number of minutes you want. For example, 60 for 1 hour or 120 for two hours.
We hope this article helped you learn how to easily delay posts from appearing in WordPress RSS feed. You may also want to see our guide on how to show content only to RSS subscribers in WordPress.
If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.
A few months ago, Jason Grigsby’s post about autocompletion in forms1 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 heart2. 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.
What I wanted was the following:
autocomplete offered by this editorThe great thing about our development environments these days is that we build the tools we use in the technologies that we use them to write. Yes, this sounds confusing — we’ve reached code Inception. Node.js3 allows us to run JavaScript on the back end, and with Electron4 we can create installable applications for all platforms using HTML, CSS and JavaScript.
Atom5 was the first editor to use this technology and to allow for contributions by being open source, closely followed by Microsoft’s Visual Studio Code6.
Almost all of the other editors in use allow us to write extensions, plugins or snippet collections in various formats. I deliberately didn’t want to write a plugin or extension, but rather wanted to add this functionality to the core of the editor. Plugins, extensions and snippets have their merits; for example, they are easy to update. The problem is that they need to be found and installed per user. I considered autocompletion too important and wanted to hack the editor itself instead.
Both Atom and Visual Studio Code are available on GitHub and come with instructions on how to extend them. The challenge is that this can feel daunting. I’m here today to show you that it isn’t as tough as you might think. Visual Studio Code is my current editor, and it features amazing autocompletion. That’s what I wanted to tackle.
Extensible and customizable tools are nothing new. Most of what we use can be extended in one way or another, whether in the form of add-ons, plugins or specialist languages. The first editor I used in anger was Allaire and Macromedia’s HomeSite7, which had funky languages like VTML8, WIZML9 and JScript, the Windows version of JavaScript at the time. I wrote a lot of extensions and toolbars for that editor, which very much boosted the productivity of my company back then.
Thankfully, these days, companies understand that offering specialist languages is time wasted, when the web stack has grown to become much more interesting to build applications with.
If you download Visual Studio Code now, you will see that my autocomplete feature is a part of it. And here is how I did that.
My first step was to go to Visual Studio Code’s GitHub repository10 and file an issue11 requesting this feature for the editor. This could also be your final step if you don’t want to do it yourself. Someone else who is looking for something to do for the project might find your complaint and tackle it for you. In my case, I wanted to find out more.
Instead of just filing an issue, I went to the GitHub repository and forked the code. I used my personal account for this. You don’t need to be affiliated with Microsoft or get added to a special group. The repository is public and open. Everybody is welcome. There is even a code of conduct for contributions12, which means that people should be playing nice. I downloaded the code to my hard drive and followed the instructions on how to build the editor locally.
Visual Studio Code is written in Node.js and TypeScript. The development flow starts with a script provided by the team, which gives me a development version of Visual Studio Code running next to the one I am using. A script running on the command line ensures that my changes are captured and that every time I save my code, the development version of the editor restarts and I can test the changes. All of this is nicely documented, from building and running the code from source13 to setting up the development workflow14. And it is independent of platform — you get instructions for Windows, Linux and Mac OS X.
You can see what this looks like on my computer in the following screenshot. The large-view editor (1) is the one I use to code the other; the one on the right (3) is the development edition; and on the bottom (2) is the script creating the new version of the development edition. Writing an editor in an editor does feel odd, but you get used to it.
15Don’t get discouraged if all of this doesn’t work for you on the first go. I hit a few snags and had to turn to Google and StackOverflow for solutions. The Node.js community was very helpful.
Next, I was ready to go all in and use TypeScript to write some clever code. I understood that this is where a lot of people throw in the towel, considering it too tough to continue.
My biggest issue was that I had no idea where to begin with this functionality. So, I did what we all do: I did a full text search for autocomplete in the whole project. Using this highly scientific approach, I found an htmlTags.ts file17 full of tag definitions and arrays of attribute values. I looked up the input element and found this:
input: new HTMLTagSpecification( nls.localize('tags.input', 'The input element represents a typed data field, usually with a form control to allow the user to edit the data.'), ['accept', 'alt', 'autocomplete:o', 'autofocus:v', 'checked:v', 'dirname', 'disabled:v', 'form', 'formaction', 'formenctype:et', 'formmethod:fm', 'formnovalidate:v', 'formtarget', 'height', 'inputmode:im', 'list', 'max', 'maxlength', 'min', 'minlength', 'multiple:v', 'name', 'pattern', 'placeholder', 'readonly:v', 'required:v', 'size', 'src', 'step', 'type:t', 'value', 'width']), That autocomplete:o looked interesting, so I checked where o is defined. Here’s what I found:
var valueSets: IValueSets = { … o: ['on', 'off'], … } That looked like what was happening when I added an autocomplete attribute. To change that, I went to the standard definition of possible autocomplete values18 and copied them.
I created a new value set named inputautocomplete and pasted in the values:
var valueSets: IValueSets = { … inputautocomplete: ['additional-name', 'address-level1', 'address-level2', 'address-level3', 'address-level4', 'address-line1', 'address-line2', 'address-line3', 'bday', 'bday-year', 'bday-day', 'bday-month', 'billing', 'cc-additional-name', 'cc-csc', 'cc-exp', 'cc-exp-month', 'cc-exp-year', 'cc-family-name', 'cc-given-name', 'cc-name', 'cc-number', 'cc-type', 'country', 'country-name', 'current-password', 'email', 'family-name', 'fax', 'given-name', 'home', 'honorific-prefix', 'honorific-suffix', 'impp', 'language', 'mobile', 'name', 'new-password', 'nickname', 'organization', 'organization-title', 'pager', 'photo', 'postal-code', 'sex', 'shipping', 'street-address', 't].sort()el-area-code', 'tel', 'tel-country-code', 'tel-extension', 'tel-local', 'tel-local-prefix', 'tel-local-suffix', 'tel-national', 'transaction-amount', 'transaction-currency', 'url', 'username', 'work'], … } I then went to all of the definitions of elements that support autocomplete and replaced the o with my own inputautocomplete:
input: new HTMLTagSpecification( nls.localize('tags.input', 'The input element represents a typed data field, usually with a form control to allow the user to edit the data.'), ['accept', 'alt', 'autocomplete:inputautocomplete' … ]), I saved my changes; the script rebuilt the editor; I tried the development version of the editor; and autocomplete worked the way I wanted it to.
That was that. I committed my changes to Git (inside Visual Studio Code19), went to GitHub and added a pull request. A few days later, I got a comment saying that my pull request went through and that what I did would be part of the next build.
Frankly, I didn’t think this was amazing enough to warrant a change to the core of the editor. I just wanted to play around. Many of you might think the same about the work you do. And that’s the thing: We’re wrong. Contributing to open-source projects doesn’t require you to be an amazing developer. Nor does it require you to be famous or part of the in-crowd. Sometimes all you need to do is look at something, analyze it and find a way to improve it.
It is up to us to make the tools we use better. If you see a way to contribute to an open-source project, don’t be shy. You might be the one who comes up with an idea so obvious and so simple that others have overlooked it. You might be the one who makes something more usable or nicer to look at. We all have skills to contribute. Let’s do more of that.
(al)
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.
↑ Back to topTweet itShare on Facebook
Do you want to change the author of a post in WordPress? Sometimes you may need to display a different author, then the person who added the post in WordPress. You do not need to copy and paste the entire WordPress post with a different user account. In this article, we will show you how to easily change the author of a post in WordPress with just a few clicks.
If you just want to show your own name on a post written by some other user on your WordPress site, then you are ready to follow the instructions in this article.
On the other hand, if you want to show a different user as author, then first you need to make sure that this user exists on your WordPress site. See our guide on how to add new users and authors in WordPress for detailed instructions.
You can see and manage all users on your WordPress site by visiting the Users page when logged in with your WordPress administrator account.
If you just want to change the way your name is displayed, then check out our guide on how to add or change your full name in WordPress.
Having said that, let’s see how to quickly and easily change the author of a post in WordPress.
First you need to edit the post or page where you want to change the author name. On the post edit screen, you need to click on the Screen Options menu at the top right corner of the screen.
This will show a flydown menu on the screen with a bunch of options. You need to check the box next to ‘Author’ option.
After that, you need to scroll down on the post edit screen just below the post editor. You will see the Author box there.
Simply click on the drop down menu and select a different author.
Don’t forget to click on the Save Draft or Update button to save your changes.
That’s all, you have successfully changed the author of a post in WordPress.
Changing author by editing a post is easy. However, if you have to do this for multiple posts, then it would take quite a lot of time to do that.
There is an easier way to quickly change author for multiple WordPress posts at once. To bulk update authors, click on the Posts menu from your WordPress admin bar. This will list all the posts on your WordPress site.
By default, WordPress shows 20 posts per page. If you want to display more posts, then you need to click on the Screen Options and change the number of posts you want to display.
Now you need to select the posts where you want to change the author. After selecting posts, select ‘Edit’ from ‘Bulk Actions’ dropdown menu and then click the ‘Apply Button’.
WordPress will now show you Bulk Edit metabox. You need to select the new author by clicking on the dropdown menu next to Author option.
Don’t forget to click on the ‘Update’ button to store your changes.
That’s all, you have successfully changed the author for multiple WordPress posts without editing them individually.
We hope this article helped you learn how to change the author of a post in WordPress. You may also want to see our comparison of the best WordPress backup plugins.
If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.