Little Smashing Stories

Original Source: https://smashingmagazine.com/2021/05/little-smashing-stories/

This is not a regular Smashing article. Over a decade ago, we set out to send a truly smashing newsletter with useful tips and techniques for designers and developers. The first issue was sent out in early 2009. And we would have never imagined that we’d reach 190.000 wonderful folks like you, who read email every other week. In fact, most newsletters we send out these days have pretty much stayed true to our original course that we set out back in the day.

Today, we have a little celebration for our 300th newsletter edition which coincides with the birthday of our incredible illustrator Ricardo Gimenes who is the creative mind behind all of the Smashing Cats (over 150, and still counting!). Ricardo must be dreaming in cats at this point. Happy birthday, dear Ricardo! (Please sing along, if possible.)

In this post, we show stories of some of the people behind these weekly newsletters, and our little magazine. We asked everyone on the team to share a personal story, something from their memories, childhood or anything that made a world difference to them. These stories are the heart of this little article.

But of course you — yes, you, dear reader, and your story — are at the heart of this issue as well. We’d love to hear your story on Twitter and in the comments. When you started reading the newsletter, and perhaps how a little tip in the newsletter helped you in some way.

And of course, thank you so much for being and staying smashing. I would love to meet you, and hear your story, and I’m very hopeful that we all will be able to do just that in the nearest future.

— Vitaly (@smashingmag)

Esther Fernández (Sponsorships)

Last week, as my parents were tidying up the family house, they came across some old pictures that they chose to share with me. Amongst them was this old picture of me proudly standing on the top of an olive tree in the wild spaces that once surrounded my hometown.

The photo arrived at the perfect time. As a mirror, it reminded me of who I once was and who I still am. At times when I have to confront some of my deepest fears, this picture proves to me that I have the audacity of climbing and standing, hands-free.

Iris Lješnjanin (Editorial)

I had just turned five when my parents and I moved from Slovenia to the United Arab Emirates where I lived until high school. Later on, with my friends and family scattered all across the globe, I remember missing them so much that I made a promise to myself to write letters and send pictures so that we could stay in touch — even though it sometimes took ages to get one back or I never even heard back from them.

I loved collecting stickers, postcards, and different types of paper to write on, and even found penpals who also shared my passion of writing and lived in Germany, Bosnia, Australia, and even Brunei (just to name a few).

Later on, when communication turned into emails and chatting via various messaging apps (does anyone else still remember mIRC, MSN, and ICQ?), the hand-written letters slowly stopped filling our mailbox and all of the writing was turned into endless typing alongside emoticons and all sorts of ASCII art.

Still, I remember printing out my favorite emails on a continuous form paper (the one with punched holes on the sides), just so that I’d always have them at hand and could read them along with the other letters kept away in my memory box that I kept on the top shelf of my closet.

Now that I’m in my 30’s, I still love getting snail mail, and especially in times like these, a letter can be a considerate and gentle way to reach out to someone and not make them feel like they’re pressured to get back to you right away. (Dear Inbox, I’m looking at you.) There’s something special about writing letters. It’s a piece of paper that creates a sort of intimacy and connection that cannot be felt online.

It’s a sign that somebody has actually taken their time to sit down and prepare something just for you. It’s a piece of paper with somebody’s gentle touch who wrote down meaning into some words while thinking about you and put it in an envelope beautifully wrapped — with not just any stamp. That truly makes every letter I’ve ever received quite unique, special, and dear to my heart.

Before I joined Smashing, Vitaly had already started sending out the Smashing Newsletter, and what actually started out as a fun writing project for the entire team, turned into something so precious and valuable that we can’t imagine ourselves without today. Not only is it an opportunity to connect with folks who share their passion for the web, but it also allows us to contribute to designers and developers by shining the spotlight on those who don’t get the credit and attention they truly deserve for their dedication and hard work.

It is with that same enthusiasm of personally writing each and every letter that we (on behalf of the Smashing team) would like to personally say “Thank you” with each and every Smashing email newsletter that we send out. A heartfelt thanks to both those who share their work online, as well as you, dear reader, for sticking around throughout the years while supporting and inspiring others by simply spreading the word.

Alma Hoffmann (Editorial)

I’ve been in a long distance relationship with Smashing since 2010. It all started with a tweet from Vitaly looking for writers. I replied. The rest is history. Met Vitaly, Iris, Markus, Ricardo, Inge, Rachel, Amanda, and many others in person in 2017. It was one of the biggest highlights in my career.

I walked around with Iris looking for a sweater because I was so cold. We hustled as we walked around the streets finding the stores. She took me to stores to buy gifts to bring back home. And we did it all practically under an hour. She gave me a sketchbook which I filled with photos of Freiburg and a canary yellow bag which I still use to carry my art supplies around town. Love my bag! Some years before, I was having a sad day and on the mail was a gift from Smashing. It made my day!

I love working at Smashing. The commitment to quality is not only impressive, but also, an unifying element that keep all of us connected to a single purpose: to be the best magazine about web development and design. I’ve become a better writer because of it.

Jarijn Nijkamp (Membership)

I have worked in or ‘around’ the educational field for the better part of my professional life, and helping people find their path is just the coolest thing. I still feel very happy (and a bit proud) when an old student gets in touch and shares something with me — either personal or professional.

The other day I found this nice graduation photo from the first ‘cohort’ I taught and managed. A very international bunch of great students who have since grown up to be wonderful people!

Vitaly Friedman (Editorial)

I used to travel somewhere almost every week: from one place to another, between projects, conferences, workshops and just random coffee breaks in favorite places in the world. Back in 2013, I moved out of my apartment without moving in anywhere. I gave away all my belongings to a homeless shelter, and decided to run a creative experiment, traveling from one place to another. I’ve been privileged to have visited an incredible amount of places, and meet an incredible amount of remarkable people, and that experiment never really stopped.

Until 2020. It was a difficult and remarkably unsettling transition for me personally, but it did give me an extremely refreshing perspective on how things can be. We move forward by inertia at times, but stopping and looking around and revisiting things is such a healthy exercise in self-understanding. Over the last year, I’ve rediscovered the beauty of a mouse, secondary screen and a comfy external keyboard. I’ve learned about the importance of true, meaningful, deep relationships. Of letting go, and embracing things that lie in your heart. In my case, it’s writing, editing, building, designing.

I even started feeling comfortable in the online space with our online workshops, and having more focused time to write and code and build and design. I still miss traveling a lot, and can’t wait to meet dear friends all over the world in person. But it’s not as bad as I thought it would be a year ago. The new remote world changed my perspective around myself, and if anything, I can now make a more balanced and conscious choice of how to shape the future. And that’s a decision I won’t take lightly.

Amanda Annandale (Events)

I’ve been at Smashing for over four years, but that was all possible because of a small decision that completely changed my life ten years ago. I was a Stage and Event Manager in NYC, and decided to take a freelance job running events. In my first event, I assisted the ‘Carsonified/Future Of…’ event while working on the “Avenue Q” stage. Their team was lovely, including their tech guy, who has since become my husband!

After moving to England to be with my husband, I was able to spend more time with the ‘Carsonified/Future Of…’ friends, and one of them was just moving on from a job at Smashing. She introduced me to the the Smashing team, where I joined just a few months later. In an amazing twist, the first SmashingConf I produced was on that very same “Avenue Q” stage, where my Smashing journey began nearly ten years ago — over five years before I joined the team!

We’d Love To Hear Your Story!

These are just a few of our stories, but all of us have some as well. We’d love to hear yours! What changed your point of view around the world? What makes you smile and happy? What memory keeps your optimistic and excited about the future?

Or perhaps you have a story of how you learned about the newsletter in the first place, and when you first started reading it? We’d love to hear your story, perhaps how a little tip in the newsletter helped you in some way. And yet again, thanks for being smashing, everyone!

Frustrating Design Patterns That Need Fixing: Birthday Picker

Original Source: https://smashingmagazine.com/2021/05/frustrating-design-patterns-birthday-picker/

You’ve seen them before. Confusing and frustrating design patterns that seem to be chasing you everywhere you go, from one website to another. Perhaps it’s a disabled submit button that never communicates what’s actually wrong, or tooltips that — once opened — cover the input field just when you need to correct a mistake. They are everywhere, and they are annoying, often tossing us from one dead-end to another, in something that seems like a well-orchestrated and poorly designed mousetrap.

These patterns aren’t malicious nor evil. They don’t have much in common with deceptive cookie prompts or mysterious CAPTCHAs in disguise of fire hydrants and crosswalks. They aren’t designed with poor intentions or harm in mind either: nobody wakes up in the morning hoping to increase bounce rates or decrease conversion.

It’s just that over the years, some more-or-less random design decisions have become widely accepted and adopted, and hence they are repeated over and over again — often without being questioned or validated by data or usability testing. They’ve become established design patterns. And often quite poor ones. Showing up again and again and again among user complaints during testing.

In this new series of articles, let’s take a closer look at some of these frustrating design patterns and explore better alternatives, along with plenty of examples and questions to keep in mind when building or designing one. These insights are coming from user research and usability tests conducted by yours truly and colleagues in the community, and of course, they all will be referenced in each of the upcoming posts.

We’ll start with a humble and seemingly harmless pattern that we all had experienced at some point — the infamous birthday picker that too often happens to be inaccessible, slow and cumbersome to use.
We’ve written about perfect date and time pickers in much detail already, but birthday pickers deserve a separate conversation.

Frustrating UX: Birthday Dropdown/Widgets Starting In 2021

Every time you apply for a job application, open a bank account or book a flight, you probably will have to type in your date of birth. Obviously, the input is a date, and so it shouldn’t be very surprising to see interfaces using a well-adopted date-picker-calendar-alike widget (native or custom), or a drop-down to ask for that specific input.

We can probably spot the reasons why these options are often preferred. From the technical standpoint, we want to ensure that the input is correct, and catch errors early. Our validation has to be bulletproof enough to validate the input, provide a clear error message and explain what exactly the customer needs to do to fix it. We just don’t have all these issues with a dropdown or a calendar widget. Plus, we can easily prevent any locale or formatting differences by providing only the options that would fit the bill.

So it’s not uncommon to see dropdowns considered the UI of last resort, and usually replaced with buttons (e.g. for filters), toggles, segmented controls, or autocomplete boxes that combine the flexibility of a text box with the assurance of a <select>-box. Dropdowns aren’t bad per se; it’s just users spend way more time than necessary filling in the data in them.

And then there is a question about default values. While with dropdowns we often default to no input whatsoever (mm/dd/yyyy), with a date picker we need to provide some starting point for the calendar view. In the latter case, ironically, the “starting” date usually happens to be just around the date of when the form is filled, e.g. May 15th, 2021. This doesn’t appear optimal of course, but what should be the right date? We need to start somewhere, right?

Well, there really isn’t a right date though. We could start early or late, 3 months ago or tomorrow, but in the case of a birthday picker, all of these options are pure guesswork. And as such, they are somewhat frustrating: without any input, customers might need to scroll all the way from 1901 to the late 1980s, and with some input set, they’ll need to correct it, often jumping decades back and forth. That interaction will require impeccable precision in scrolling.

No matter what choice we make, we will be wrong almost all the time. This is likely to be different for a hotel booking website, or a food delivery service, and plenty of other use cases — just not birthday input. This brings us to the conversation about how to objectively evaluate how well-designed a form input is.

Evaluating The Quality Of Form Design

Design can be seen as a very subjective matter. After all, everybody seems to have their own opinion and preferences about the right approach for a given problem. But unlike any kind of self-expression or art, design is supposed to solve a problem. The question, then, is how well a particular design solves a particular problem. The more unambiguous the rendering of designer’s intent, the fewer mistakes customers make, the less they are interrupted, the better the design. These attributes are measurable and objective.

In my own experience, forms are the most difficult aspect of user experience. There are so many difficult facets from microcopy and form layout to inline validation and error messages. Getting forms right often requires surfacing back-end errors and third-party errors properly to the front-end and simplifying a complex underlying structure into a set of predictable and reasonable form fields. This can easily become a frustrating nightmare in complex legacy applications and third-party integrations.

So, when it comes to form design, in our projects, we always try to measure the quality of a particular solution based on the following 9 attributes:

Mental model
How well does our form design fit into the mental model of the customer? When asking for personal details, we need to ask exactly the minimum of what’s required for us to help our customers get started. We shouldn’t ask for any sensitive or personal details (gender, birthday, phone number) unless we have a good reason for it, and explain it in the UI.
Complexity
How many input elements do we display per page, on mobile and on desktop? If a form contains 70–80 input fields, rather than displaying them all on one page, or use a multi-column layout, it might be a good idea to use a task list pattern to break down complexity into smaller, manageable chunks.
Speed of input
How much time and effort does the customer need to fill in data correctly? For a given input, how many taps/keystrokes/operations are required to complete the form with a given data accurately, assuming that no mistakes are done along the way.
Accessibility
When speaking about the speed of input, we need to ensure that we support various modes of interaction, primarily screen reader users and keyboard users. This means properly set labels, large buttons, labels placed above the input field, and errors properly communicated, among many other things.
Scalability
If we ever needed to translate the UI to another language or adapt it for another form factor, how straightforward would it be, and how many issues will it cause? (A typical example of a problematic solution is a floating label pattern, and we’ll talk about it in a separate post.)
Severity of interruptions
How often do we interrupt customers, be it with loading spinners, early or late inline validation, freezing parts of the UI to adjust the interface based on provided UI (e.g. once a country is selected), the frequency of wrongly pre-filled data, or wrongly auto-corrected data?
Form success rate
How many customers successfully complete a form without a single mistake? If a form is well designed, a vast majority of customers shouldn’t ever see any errors at all. For example, this requires that we tap into browser’s auto-fill, the tab order is logical and making edits is conventional and obvious.
Speed of recovery
How high is the ratio of customers who succeed in discovering the error, fixing it, and moving along to the next step of the form? We need to track how often error messages appear, and what error messages are most common. That’s also why it’s often a good idea to drop by customer support and check with them first what customers often complain about.
Form failure rate
How many customers abandon the form? This usually happens not only because of the form’s complexity, but also because customers can’t find a way to fix an error due to aggressive validators or disabled “submit” buttons. It also happen happens because the form asks too much sensitive and personal information without a good reason.

To understand how well a form works, we run usability studies with customers accessing the interface on their own machine — be it mobile device, tablet, laptop or desktop — on their own OS, in their own browser. We ask to record the screen, if possible, and use a thinking-aloud protocol, to follow where and how and why mistakes happen. We also study how fast the customer is moving from one form field to another, when they pause and think, and when most mistakes happen.

Obviously, the sheer number of taps or clicks doesn’t always suggest that the input has been straightforward or cumbersome. But some modes of input might be more likely to generate errors or cause confusion, and others might be outliers, requiring just way more time compared to other options. That’s what we are looking for in tests.

Now, let’s see how we can apply it to the birthday input problem.

Designing A Better Birthday Input

If somebody asks you for your birthday, you probably will have a particular string of digits in mind. It might be ordered in dd/mm/yyyy or mm/dd/yyyy, but it will be a string of 8 digits that you’ve been repeating in all kinds of documents since a very young age.

We can tap into this simple model of what a birthday input is with a simple, single-input field which would combine all three inputs — day, month, and year. That would mean that the user would just type a string of 8 numbers, staying on the keyboard all the time.

However, this approach brings up a few issues:

we need to support auto-formatting and masking,
we need to explain the position of the day/month input,
we need to support the behavior of the Backspace button across the input,
we need to track and hide/show/permanently display the masking,
we need to support jumps into a specific value (e.g. month),
we need to minimize rage clicks and navigation within the input to change a specific value on mobile devices,
If auto-making isn’t used, we need to come up with a set of clean-up and validation rules to support any kind of delimiters.

In his book on Form Design Patterns, Adam Silver argues that using multiple inputs instead of one input is rarely a good idea, but it is a good option for dates. We can clearly communicate what each input represents, and we can highlight the specific input with focus styles. Also, validation is much easier, and we can communicate easily what specific part of the input seems to be invalid, and how to fix it.

We could either automatically transition the user from one input to the next when the input is finished, or allow users to move between fields on their own. At the first glance, the former seems better as the input would require just 8 digits, typed one after another. However, when people fix errors, they often need input buffers — space within the input field to correct existing input.

For example, it’s common to see people typing in 01, realizing that they made a mistake, then changing the input to 010, and then removing the first 0, just to end up with a reversed (and correct) string — 10. By avoiding an automatic transition from one field to the next, we might be causing less trouble and making the just UI a bit more predictable and easy to deal with.

To explain the input, we’d need to provide labels for the day, month and year, and perhaps also show an example of the correct input. The labels shouldn’t be floating labels but could live comfortably above the input field, along with any hints or examples that we might want to display. Plus, every input could be highlighted on focus as well.

Over the years, I couldn’t spot a single problem with this solution throughout years of testing, and it’s not surprising the pattern being used on Gov.uk as well.

When You Need A Date Picker After All

While the solution above is probably more than enough for a birthday input, it might not be good enough for more general situations. We might need a date input that’s less literal than a birth day, where customers will have to pick a day rather than provide it (e.g. “first Saturday in July”). For this case, we could enhance the three input fields with a calendar widget that users could use as well. A default input would depend on either the current date, or a future date that most customers tend to choose.

Adam provides a simple code example for the Memorable date pattern in his NoStyle Design System. It solves plenty of development work and avoids plenty of accessibility issues, and all of that by avoiding tapping around calendar widgets or unnecessary scrolling around dropdown wheels.

Wrapping Up

Of course, a good form control depends on the kind of date input that we are expecting. For trip planners, where we expect customers to select a date of arrival, a flexible input with a calendar look-up might be useful.

When we ask our customers about their date of birth though, we are asking for a very specific date — a very specific string, referring to an exact day, month, and year. In that case, a drop-down is unnecessary. Neither is a calendar look-up, defaulting to a more-or-less random value. If you do need one, avoid native date pickers and native drop-downs if possible and use an accessible custom solution instead. And rely on three simple input fields, with labels and explanations placed above the input field.

We’ve also published a lengthy opus on designing a perfect date and time picker, along with checklists you might want to use to design or build one.

Related Articles

If you find this article useful, here’s an overview of similar articles we’ve published over the years — and a few more are coming your way.

Perfect Responsive Configurator
Perfect Feature Comparison
Perfect Slider
Perfect Accordion
Form Design Patterns Book by Adam Silver, published on SmashingMag
Subscribe to our email newsletter to not miss the next ones.

Noisy Strokes Texture with Three.js and GLSL

Original Source: http://feedproxy.google.com/~r/tympanus/~3/ZsQOFDvg5Hc/

In this ALL YOUR HTML coding session you’ll learn how to recreate the amazing noisy strokes texture seen on the website of Leonard, the inventive agency, using Three.js with GLSL. The wonderful effect was originally made by Damien Mortini.

This coding session was streamed live on May 9, 2021.

Support: https://www.patreon.com/allyourhtml

Setup: https://gist.github.com/akella/a19954…

The post Noisy Strokes Texture with Three.js and GLSL appeared first on Codrops.

Collective #660

Original Source: http://feedproxy.google.com/~r/tympanus/~3/QSbXhSak_Hg/

Inspirational Website of the Week: Paul & Henriette

Sharp minimalism with great typography and a focus on beautiful image and layout animations. Our pick this week.

Get inspired

Collective 643 item image

Our Sponsor
Instant websites for your clients with Divi Layout Packs

With the Divi Layout Packs you’ll get world-class designs ready to be used for your client projects.

Check it out

The Humble <img> Element And Core Web Vitals

An excerpt from Addy Osmani’s new book Image Optimization.

Read it

Portfolio 2021 technical case study — Rendering a whole HTML website in WebGL

Martin Laxenaire shows how he created his portfolio using his own vanilla JavaScript open source tools.

Read it

Container Queries Explainer & Proposal

Miriam Eric Suzanne explains the proposed solution for container queries and shows how to use them.

Read it

The State of CSS Cross-Browser Development

Ahmad Shadeed thoughts on why cross-browser development is better than in the past.

Read it

Mantine

Mantine is a React components and hooks library with native dark theme support and focus on usability, accessibility and developer experience.

Check it out

Two options for using custom properties

Peter-Paul Koch shares an efficient way of using custom properties for component styling.

Read it

Toggling CSS Custom Properties with Radio Buttons

Michelle Barker explains how to use custom properties for a toggle functionality.

Read it

Iconic

A fantastic set of pixel-perfect icons with new icons added every week.

Check it out

Scroll-Linked Animations with CSS Scroll-Timeline (CSS Café)

Bramus shares his talk covering Scroll-Linked Animations with CSS @scroll-timeline on CSS Café.

Check it out

Fluid Typography

Calculate CSS declarations for beautiful fluid typography headings. Made by Erik André.

Check it out

(t,i,x,y,z) => “creative code golfing”

A minimalist three-dimensional coding environment. Control 8x8x8 dots with a single JavaScript function.

Check it out

Fower

A utility-first CSS-in-JS library for rapid UI development.

Check it out

CSS Cuboid Generator

A fantastic cuboid generator made with React and Prism by Jhey.

Check it out

Profiling site speed with the Chrome DevTools Performance tab

Learn how to use the Chrome DevTools Performance tab to measure and improve the speed of your website.

Read it

3D Game Shaders For Beginners

A step-by-step guide to implementing SSAO, depth of field, lighting, normal mapping, and more for your 3D game.

Check it out

Exploring color-contrast() for the First Time

Chris Coyier explores the color-contrast() function in CSS which is freshly supported in Safari Technical Preview 122.

Read it

How to Create Actions for Selected Text With the Selection API

Preethi shows how to reveal an options panel when selecting text on a website.

Read it

Don’t Confuse Function Expressions and Function Declarations in JavaScript

What are the differences between function declarations and function expressions in JavaScript? Find out in this article by Dmitri Pavlutin.

Read it

Measuring Web Performance in 2021: The Definitive Guide

A guide to the metrics, methods, and measurements of web performance in 2021.

Check it out

From Our Blog
Dynamic CSS Masks with Custom Properties and GSAP

Learn how to animate CSS masks based on the cursor position using GSAP and custom properties for a unique spotlight effect in this article by Michelle Barker.

Read it

The post Collective #660 appeared first on Codrops.

Create Beautiful WordPress Pages with Optimized Images Using Elementor and ImageEngine

Original Source: https://www.webdesignerdepot.com/2021/05/create-beautiful-wordpress-pages-with-optimized-images-using-elementor-and-imageengine/

WordPress powers nearly 40% of all websites, thanks to its commitment to making publication possible for everyone, for free. Combined with premium plugins and themes, it’s possibly the ultimate tool for building attractive, unique, and feature-rich websites without any coding or design experience.

However, you do pay the price for this experience, with WordPress and its third-party products not always being built for performance – whether it’s page loading times or SEO.

Image optimization is a particularly big concern. Images are one, if not the largest, contributors to page weight, and it’s growing significantly by the year. So, while images are crucial for beautifying your website pages, they are also one of the biggest factors slowing it down.

In terms of image optimization, WordPress+Elementor brings very little to the table. WordPress core now comes with both responsive syntax and lazy-loading. Elementor itself also only comes with responsive syntax out-of-the-box. However, these are baseline techniques for image optimization that will deliver the bare minimum of improvements.

This means that, while Elementor makes it easy to design sweet-looking WordPress pages (with tonnes of creatively utilized images), you will probably pay the price when it comes to performance. But don’t worry. We will show you how to dramatically improve web performance by over 30 points on scoring tools like Google’s PageSpeed Insight. 

Why Optimize Your Elementor Images with ImageEngine?

In general, image CDNs use various techniques to get image payloads as small as possible and deliver image content faster, all while minimizing the visual impact. ImageEngine is no different in that regard.

Firstly, ImageEngine, when used in auto mode, will apply all of the following optimizations that web performance tools like Google’s PageSpeed Insight recommend. For example:

Properly size images – ImageEngine automatically resizes images for optimal size-to-quality ratios depending on the screen size of the user device. ImageEngine supports Retina devices.
Efficiently encode images – Applies different rates of compression depending on the PPI of the user devices. For example, ImageEngine adapts and more aggressively compresses on higher PPI devices without losing visual quality.
Next-gen format conversion – Automatically converts images to the optimal next-gen format according to the browser, device, or OS. ImageEngine can convert images to WebP or JPEG-2000 as well as GIFs to MP4 or WebP.  AVIF is also available in a manual directive mode.
Strip unnecessary metadata

While these features are standard for most image CDNs, ImageEngine is unique for its use of WURFL device detection. This gives ImageEngine much deeper insight into the user device accessing a website page and, by extension, its images. Using the screen size, resolution, PPI, etc., ImageEngine can make more intelligent decisions regarding how to reduce image payloads while maintaining visual quality.

This is why ImageEngine brands itself as an “intelligent, device-aware” image CDN and why it can reduce image payloads by as much as 80% (if not more).

ImageEngine also provides a proprietary CDN service to accelerate image delivery. The CDN consists of 20 globally positioned PoPs with the device-aware logic built-in. This allows you to deliver image content faster in different regions while also serving images straight from the cache with a ~98% hit ratio.

ImageEngine also supports Chrome’s save data setting. If someone has a slow connection or has activated this setting, ImageEngine will automatically compress image payloads even more, to provide a better user experience on slower connections.

How to Use ImageEngine with WordPress and Elementor

If you’re using WordPress and Elementor, then chances are you want to spend as little time on development and other technicalities as possible. Luckily, ImageEngine is a highly streamlined tool that requires little to no effort to integrate or maintain with a WordPress site.

Assuming you already have a WordPress website with Elementor, here are the step-by-step instructions to use ImageEngine:

Go to ImageEngine.io and sign up for a 30-day free trial.
Provide ImageEngine with the URL of the website you want to optimize.
Create an account (or sign up with your existing Google, GitHub, or ScientiaMobile account).
Provide ImageEngine with the current origin where your images are served from. If you upload images to your WordPress website as usual, then that means providing your WordPress website address again.
Finally, ImageEngine will generate an ImageEngine delivery address for you from where your optimized images will be served. This typically takes the form of: {randomstring}.cdn.imgeng.in. You can change the delivery address to something more meaningful from the dashboard, such as myimages.cdn.imgeng.in.

Now, to set up ImageEngine on your WordPress website:

Go to the WordPress dashboard and head to Plugins -> Add New.
Search for the “Image CDN” plugin by ImageEngine. When you find it, install and activate the plugin.

Go to Settings -> Image CDN. OK, so this is the ImageEngine plugin dashboard. To configure it, all you need to do is:

a. Copy the delivery address you got from ImageEngine above and paste it in the “Delivery Address” field.

b. Tick the “Enable ImageEngine” box.

That’s literally it. All images that you use on your WordPress/Elementor pages should now be served via the ImageEngine CDN already optimized. 

ImageEngine is largely a “set-it-and-forget-it” tool. It will provide the best results in auto mode with no user input. However, you can override some of ImageEngine’s settings from the dashboard or by using URL directives to manipulate images.

For example, you can resize an image to 300 px width and convert it to WebP by changing the src attribute like this:

<img src=”https://myimages.cdn.imgeng.in/wp-content/uploads/2021/03/banner-logo.png?imgeng=/w_300/f_webp”>

However, use this only when necessary, as doing so will limit ImageEngine’s adaptability under different conditions.

What Improvement Can You Expect?

Let’s see what results you can expect from using an image CDN to improve your page loading times.

For this, I created two identical WordPress pages using the Elementor theme. The one page purely relied on WordPress and Elementor, while I installed and set up ImageEngine for the other. The page had some galleries as well as full-size images:

The pages used many high-quality images, as you might expect to find on a professional photography gallery, photography blog, stock photo website, large e-commerce site, etc. I then ran page performance tests using Chrome’s built-in Lighthouse audit tool, choosing scores representing the average results I got for each page.

For thoroughness, I tested both the mobile and desktop performance. However, I focused on the mobile results as these showcase more of the image CDN’s responsive capabilities. Mobile traffic also accounts for the majority share of internet traffic and seems to be the focus for search engines going forward.

So, first of all, let’s see the mobile score for the page without ImageEngine:

As you can see, there was definitely a struggle to deliver the huge amount of image content. Google has shown that 53% of mobile users abandon a page that takes more than 3s to load. So, clearly, this page has major concerns when it comes to user experience and retaining traffic.

The desktop version fared much better, although it still left much to be desired:

When digging into the reasons behind the slowdown, we can identify the following problems:

Most of the issues related somehow to the size and weight of the images. As you can see, Lighthouse identified a 3.8 MB payload while the total image payload of the entire page was close to 40 MB.

Now, let’s see what kind of improvement ImageEngine can make to these issues by looking at the mobile score first:

So, as you can see, a major improvement of 30 points over the standard WordPress/Elementor page. The time to load images was cut down by roughly 80% across the key core web vital metrics, such as FCP, LCP, and the overall Speed Index.

In fact, we just reached that critical 3s milestone for the FCP (the largest element on the visible area of the page when it initially loads), which creates the impression that the page has finished loading and will help you retain a lot of mobile traffic.

The desktop score was also much higher, and there was further improvement across the key performance metrics.

If we look at the performance problems still present, we see that images are almost completely removed as a concern. We also managed to bring down the initial 3.8 MB payload to around 1.46 MB, which is a ~62% reduction:

An unfortunate side effect of using WordPress and WordPress plugins is that you will almost inevitably face a performance hit due to all the additional JavaScript and CSS. This is part of the reason why we didn’t see even larger improvements. That’s the price you pay for the convenience of using these tools.

That being said, the more images you have on your pages, and the larger their sizes, the more significant the improvement will be.

It’s also worth noting that lazy-loaded images were loaded markedly faster with ImageEngine if you quickly scroll down the page, again making for an improved user experience.

Thanks to its intelligent image compression, there was also no visible loss in image quality, as you can see from this comparison:

Conclusion

So, as you can see, we can achieve significant performance improvements on image-heavy websites by using the ImageEngine image CDN, despite inherent performance issues using a CMS. This will translate to happier users, better search engine rankings, and an overall more successful website.

The best part is that ImageEngine stays true to the key principles of WordPress. You don’t have to worry about any of the nuts and bolts on the inside. And, ImageEngine will automatically adjust automation strategies as needed, future-proofing you against having to occasionally rework images for optimization.

Source

p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

The post Create Beautiful WordPress Pages with Optimized Images Using Elementor and ImageEngine first appeared on Webdesigner Depot.

How To Power Through Designer Apathy

Original Source: https://www.webdesignerdepot.com/2021/05/how-to-power-through-designer-apathy/

Sometimes you just don’t give a damn anymore. Possibly the only thing worse than designer’s block is designer’s apathy: that sinking feeling you get when you realize that you just don’t care about this particular piece of work anymore is disheartening.

The dread of going back to it is paralyzing.

There are many reasons you can stop caring about your work. Maybe you’ve just done the same thing too many times in a row. Maybe your client is insisting on asking for things you know won’t work for them. Maybe something much more important just happened in your life, and you’ve got bigger things to worry about. You could be discouraged by the apparent ‘sameness’ of bandwagon-hopping designs.

I’ve been not caring about my work ever since I was first asked to pick up my toys

Whatever the reason, we all experience times when we know exactly what we have to do… we just don’t care.

I’m something of an expert on this phenomenon. I’ve been not caring about my work ever since I was first asked to pick up my toys. Worse, I have the attention span of a goldfish, even now.

Web design is different. When I discovered it, it was new, exciting, and I could do it on the computer. I loved it, and I still do. Writing code that makes design happen in a browser window will never get old for me.

But even so, sometimes, a particular project will make me want to throw up my hands in exasperation and play video games ‘til Judgement Day. I’d welcome Skynet with tacos and RPGs.

So what do we do about it? First, answer this question: who is the project for?

For A Client

If the project is for a client, it’s just gotta get done. There’s no way around that. You made a commitment. You’re going to follow through and give it your best possible effort because you’re a professional. Anything less would be wrong.

However, that doesn’t mean you have to just power through with only coffee and misery for company. There are things you can do to make the work easier on yourself. The less miserable you are while you work, the better quality you can deliver.

For Yourself

There are a couple of schools of thought here. The first is that it’s perfectly fine to give up on personal projects when you stop caring. I mean, it’s your free time. Why spend it on something you don’t care about?

On the other hand, is a commitment made to yourself any less important than a commitment made to someone else? Many people seem to be perfectly fine with breaking promises to themselves when they’d never willingly do that to a client. Is that wrong?

I usually buy myself a drink and forgive myself, but it’s worth thinking about.

The deciding factor for me is whether my personal project will have any sort of lasting benefit. If whatever I’m designing, writing, or making counts as a long-term investment in my career or quality of life, then it absolutely has to get done, even when I’m not feeling it. Otherwise, I call it a learning experience and move on.

How To Power Through

So, for whatever reason — whether because you have to, or you want to — you’re gonna power through. Here are five ways to do it in style:

1. Start

The hardest part of doing work you don’t care about is starting. This is when you’ll be tempted to procrastinate until the last minute. Try not to.

2. Switch To A Different Part Of The Project

If you can safely (without causing problems) work on a different aspect of the project for a while, try that. The mere variety, the break from the work in front of you before, can boost your morale.

Indeed, working on a different part of the project can give you ideas of getting the most troubling bits done faster or more easily.

3. Do Something Old In A New Way

This one has its pros and cons.

Pro: You can look at this project as a chance to try out a new grid framework, script, code editor, or another tool of some kind. Injecting the process of discovery into an otherwise boring project can make it a lot more fun and even make you look forward to working on it.

Con: You’ll need to plan for extra hours and use some version control; because bringing a new tool or process into play is almost guaranteed to make something interesting go wrong — when this happens, you probably shouldn’t bill the client for the extra hours spent on StackOverflow.

4) Make Like Aziz Ansari And Treat Yo’self

Celebrate the milestones of your project. Don’t celebrate with video games if you need to get any more work done that day. That can go very wrong. But do celebrate. Reward yourself because you’re doing something difficult.

Have a snack. Give yourself a round of applause. Whatever it takes, make yourself look forward.

5) Outsource It

As a last resort, you can always outsource the project to someone else. Just make sure it’s someone you can trust to deliver the same quality of work you would normally provide yourself. Make sure to check it over before handing it off to a client.

Alternatively, you could just outsource the bits of the work that you don’t like. Either way, this is a risky strategy because whoever you outsource to might experience delays or, ironically, not care about the project.

Conclusion

You can do it! I believe in you. The really, really boring projects can seem like huge sinkholes of sadness, but they don’t last forever.

 

Featured image via Pexels.

Source

p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

The post How To Power Through Designer Apathy first appeared on Webdesigner Depot.

Reducing HTML Payload With Next.js (Case Study)

Original Source: https://smashingmagazine.com/2021/05/reduce-data-sent-client-nextjs/

I know what you are thinking. Here’s another article about reducing JavaScript dependencies and the bundle size sent to the client. But this one is a bit different, I promise.

This article is about a couple of things that Bookaway faced and we (as a company in the traveling industry) managed to optimize our pages, so that the HTML we send is smaller. Smaller HTML means less time for Google to download and process those long strings of text.

Usually, the HTML code size is not a big issue, especially for small pages, not data-intensive, or pages that are not SEO-oriented. However, in our pages, the case was different as our database stores lots of data, and we need to serve thousands of landing pages at scale.

You may be wondering why we need such a scale. Well, Bookaway works with 1,500 operators and provide over 20k services in 63 countries with 200% growth year over year (pre Covid-19). In 2019, we sold 500k tickets a year, so our operations are complex and we need to showcase it with our landing pages in an appealing and fast manner. Both for Google bots (SEO) and to actual clients.

In this article, I’ll explain:

how we found the HTML size is too big;
how it got reduced;
the benefits of this process (i.e. creating improved architecture, improving ode organization, providing a straightforward job for Google to index tens of thousands of landing pages, and serving much fewer bytes to the client — especially suitable for people with slow connections).

But first, let’s talk about the importance of speed improvement.

Why Is Speed Improvement Necessary To Our SEO Efforts?

Meet “Web Vitals”, but in particular, meet LCP (Largest Contentful Paint):

“Largest Contentful Paint (LCP) is an important, user-centric metric for measuring perceived load speed because it marks the point in the page load timeline when the page’s main content has likely loaded — a fast LCP helps reassure the user that the page is useful.”

The main goal is to have a small LCP as possible. Part of having a small LCP is to let the user download as small HTML as possible. That way, the user can start the process of painting the largest content paint ASAP.

While LCP is a user-centric metric, reducing it should make a big help to Google bots as Googe states:

“The web is a nearly infinite space, exceeding Google’s ability to explore and index every available URL. As a result, there are limits to how much time Googlebot can spend crawling any single site. Google’s amount of time and resources to crawling a site is commonly called the site’s crawl budget.”

— “Advanced SEO,” Google Search Central Documentation

One of the best technical ways to improve the crawl budget is to help Google do more in less time:

Q: “Does site speed affect my crawl budget? How about errors?”

A: “Making a site faster improves the users’ experience while also increasing the crawl rate. For Googlebot, a speedy site is a sign of healthy servers so that it can get more content over the same number of connections.”

To sum it up, Google bots and Bookaway clients have the same goal — they both want to get content delivered fast. Since our database contains a large amount of data for every page, we need to aggregate it efficiently and send something small and thin to the clients.

Investigations for ways we can improve led to finding that there is a big JSON embedded in our HTML, making the HTML chunky. For that case, we’ll need to understand React Hydration.

React Hydration: Why There Is A JSON In HTML

That happens because of how Server-side rendering works in react and Next.js:

When the request arrives at the server — it needs to make an HTML based on a data collection. That collection of data is the object returned by getServerSideProps.
React got the data. Now it kicks into play in the server. It builds in HTML and sends it.
When the client receives the HTML, it is immediately pained in front of him. In the meanwhile, React javascript is being downloaded and executed.
When javascript execution is done, React kicks into play again, now on the client. It builds the HTML again and attaches event listeners. This action is called hydration.
As React building the HTML again for the hydration process, it requires the same data collection used on the server (look back at 1.).
This data collection is being made available by inserting the JSON inside a script tag with id __NEXT_DATA__.

What Pages Are We Talking About Exactly?

As we need to promote our offerings in search engines, the need for landing pages has arisen. People usually don’t search for a specific bus line’s name, but more like, “How to get from Bangkok to Pattaya?” So far, we have created four types of landing pages that should answer such queries:

City A to City B
All the lines stretched from a station in City A to a station in City B. (e.g. Bangkok to Pattaya)
City
All lines that go through a specific city. (e.g. Cancun)
Country
All lines that go through a specific country. (e.g. Italy)
Station
All lines that go through a specific station. (e.g. Hanoi-airport)

Now, A Look At Architecture

Let’s take a high-level and very simplified look at the infrastructure powering the landing pages we are talking about. Interesting parts lie on 4 and 5. That’s where the wasting parts:

Key Takeaways From The Process

The request is hitting the getInitialProps function. This function runs on the server. This function’s responsibility is to fetch data required for the construction of a page.
The raw data returned from REST Servers passed as is to React.
First, it runs on the server. Since the non-aggregated data was transferred to React, React is also responsible for aggregating the data into something that can be used by UI components (more about that in the following sections)
The HTML is being sent to the client, together with the raw data. Then React is kicking again into play also in the client and doing the same job. Because hydration is needed (more about that in the following sections). So React is doing the data aggregation job twice.

The Problem

Analyzing our page creation process led us to the finding of Big JSON embedded inside the HTML. Exactly how big is difficult to say. Each page is slightly different because each station or city has to aggregate a different data set. However, it is safe to say that the JSON size could be as big as 250kb on popular pages. It was Later reduced to sizes around 5kb-15kb. Considerable reduction. On some pages, it was hanging around 200-300 kb. That is big.

The big JSON is embedded inside a script tag with id of ___NEXT_DATA___:

<script id=”__NEXT_DATA__” type=”application/json”>
// Huge JSON here.
</script>

If you want to easily copy this JSON into your clipboard, try this snippet in your Next.js page:

copy($(‘#__NEXT_DATA__’).innerHTML)

A question arises.

Why Is It So Big? What’s In There?

A great tool, JSON Size analyzer, knows how to process a JSON and shows where most of the bulk of size resides.

That was our initial findings while examining a station page:

There are two issues with the analysis:

Data is not aggregated.
Our HTML contains the complete list of granular products. We don’t need them for painting on-screen purposes. We do need them for aggregation methods. For example, We are fetching a list of all the lines passing through this station. Each line has a supplier. But we need to reduce the list of lines into an array of 2 suppliers. That’s it. We’ll see an example later.
Unnecessary fields.
When drilling down each object, we saw some fields we don’t need at all. Not for aggregation purposes and not for painting methods. That’s because We fetch the data from REST API. We can’t control what data we fetch.

Those two issues showed that the pages need architecture change. But wait. Why do we need a data JSON embedded in our HTML in the first place? ?

Architecture Change

The issue of the very big JSON had to be solved in a neat and layered solution. How? Well, by adding the layers marked in green in the following diagram:

A few things to note:

Double data aggregation was removed and consolidated to just being made just once on the Next.js server only;
Graphql Server layer added. That makes sure we get only the fields we want. The database can grow with many more fields for each entity, but that won’t affect us anymore;
PageLogic function added in getServerSideProps. This function gets non-aggregated data from back-end services. This function aggregates and prepares the data for the UI components. (It runs only on the server.)

Data Flow Example

We want to render this section from a station page:

We need to know who are the suppliers are operating in a given station. We need to fetch all lines for the lines REST endpoint. That’s the response we got (example purpose, in reality, it was much larger):

[
{
id: “58a8bd82b4869b00063b22d2”,
class: “Standard”,
supplier: “Hyatt-Mosciski”,
type: “bus”,
},
{
id: “58f5e40da02e97f000888e07a”,
class: “Luxury”,
supplier: “Hyatt-Mosciski”,
type: “bus”,
},
{
id: “58f5e4a0a02e97f000325e3a”,
class: ‘Luxury’,
supplier: “Jones Ltd”,
type: “minivan”,
},
];
[
{ supplier: “Hyatt-Mosciski”, amountOfLines: 2, types: [“bus”] },
{ supplier: “Jones Ltd”, amountOfLines: 1, types: [“minivan”] },
];

As you can see, we got some irrelevant fields. pictures and id are not going to play any role in the section. So we’ll call the Graphql Server and request only the fields we need. So now it looks like this:

[
{
supplier: “Hyatt-Mosciski”,
type: “bus”,
},
{
supplier: “Hyatt-Mosciski”,
type: “bus”,
},
{
supplier: “Jones Ltd”,
type: “minivan”,
},
];

Now that’s an easier object to work with. It is smaller, easier to debug, and takes less memory on the server. But, it is not aggregated yet. This is not the data structure required for the actual rendering.

Let’s send it to the PageLogic function to crunch it and see what we get:

[
{ supplier: “Hyatt-Mosciski”, amountOfLines: 2, types: [“bus”] },
{ supplier: “Jones Ltd”, amountOfLines: 1, types: [“minivan”] },
];

This small data collection is sent to the Next.js page.

Now that’s ready-made for UI rendering. No more crunching and preparations are needed. Also, it is now very compact compared to the initial data collection we have extracted. That’s important because we’ll be sending very little data to the client that way.

How To Measure The Impact Of The Change

Reducing HTML size means there are fewer bits to download. When a user requests a page, it gets fully formed HTML in less time. This can be measured in content download of the HTML resource in the network panel.

Conclusions

Delivering thin resources is essential, especially when it comes to HTML. If HTML is turning out big, we have no room left for CSS resources or javascript in our performance budget.

It is best practice to assume many real-world users won’t be using an iPhone 12, but rather a mid-level device on a mid-level network. It turns out that the performance levels are pretty tight as the highly-regarded article suggests:

“Thanks to progress in networks and browsers (but not devices), a more generous global budget cap has emerged for sites constructed the “modern” way. We can now afford ~100KiB of HTML/CSS/fonts and ~300-350KiB of JS (gzipped). This rule-of-thumb limit should hold for at least a year or two. As always, the devil’s in the footnotes, but the top-line is unchanged: when we construct the digital world to the limits of the best devices, we build a less usable one for 80+% of the world’s users.”

Performance Impact

We measure the performance impact by the time it takes to download the HTML on slow 3g throttling. that metric is called “content download” in Chrome Dev Tools.

Here’s a metric example for a station page:

HTML size (before gzip)
HTML Download time (slow 3G)

Before
370kb
820ms

After
166
540ms

Total change
204kb decrease
34% Decrease

Layered Solution

The architecture changes included additional layers:

GraphQl server: helpers with fetching exactly what we want.
Dedicated function for aggregation: runs only on the server.

Those changed, apart from pure performance improvements, also offered much better code organization and debugging experience:

All the logic regarding reducing and aggregating data now centralized in a single function;
The UI functions are now much more straightforward. No aggregation, no data crunching. They are just getting data and painting it;
Debugging server code is more pleasant since we extract only the data we need—no more unnecessary fields coming from a REST endpoint.

The cheapest laptops on sale in April 2021: Our expertly selected deals

Original Source: http://feedproxy.google.com/~r/CreativeBloq/~3/rn01j1v0Sw0/cheap-laptop-deals

Get a bargain with the cheapest laptops on sale.