Tag: Websites

Reduce Your Website’s Environmental Impact With a Carbon Budget

As I write this, world leaders are gathering in Glasgow for COP26, the international climate change conference, in the attempt to halt (or at least slow down) catastrophic climate change by pledging to end their countries’ dependence on fossil fuels. Only time will tell whether they will succeed (spoiler: it’s not looking good), but one thing that’s increasingly clear is that we in the tech industry can no longer bury our heads in the sand. We all have a responsibility to ensure our planet is habitable for future generations.

It’s all too easy to disassociate climate change from the web. After all, most of us are sitting at our desks day in, day out. We don’t physically see the emissions the web is producing. But according to a report by the BBC in 2020, the internet accounts for 3.7% of carbon emissions worldwide — and rising. That puts our industry on level with the entire air travel industry. So, when I think of what we can do to make our websites “better” I immediately think of how we can make them better for the planet. Because, like it or not, the carbon emissions produced by our websites not only impact our own users, but all the people who don’t use our websites too. We certainly have a lot of work to do.

It’s no secret that web pages have been becoming increasingly bloated. The average web page size now stands at around 2MB. This is terrible news for users, whose experience of browsing such bloated sites will be very poor on slow connections, but it’s also terrible for the planet. Poor performance and energy intensity often go hand in hand. But happily, it means that fixing one will go a long way towards fixing the other — it’s a win-win. So what’s one thing we can do to improve the environmental impact of our websites (and, by extension, improve performance for our users too)?

My suggestion is that we need to set our websites a carbon budget.

Performance budgets in web development are not a new idea, and in many respects go hand-in-hand with carbon budgets. Optimizing for performance should generally have a positive impact on your website’s energy efficiency. But a quantifiable carbon budget as well helps us look at every aspect of our website through the lens of sustainability, and may help us consider aspects that a performance budget alone wouldn’t cover.

How can we begin to calculate a carbon budget for our site? Calculating the amount of carbon produced by a web page is difficult due to the many factors to consider: there’s the power used during development, the data centers that host our files, the data transfer itself, the power consumed by the devices of our end users, and more. It would be virtually impossible to perform our own calculations every time we build a website. But Wholegrain Digital’s Website Carbon Calculator tool, which estimates the carbon footprint of a given website, gives us a good jumping-off point from which to start thinking about this stuff.

Screenshot of the COP26 homepage with a deep blue background, bold white and green lettering on the left with the conference dates, and a swirly illustration of Earth on the right in green and white.
The COP26 site is dirtier than 94% of web pages tested by the Web Carbon Calculator

Let’s take the COP26 website as an example. Running this site through the Carbon Calculator reveals some fairly shocking results: The site is dirtier (i.e. more carbon intensive) than 94% of web pages tested by the tool. Inspecting the homepage in DevTools, we can see that entire page weighs in at around 6.4MB of transferred data — way about average, but sadly not unusual. Further inspection reveals that JavaScript from social media embeds (including YouTube video embeds) are among the worst offenders on the homepage, contributing significantly to the page weight. Fershad Irani has written this detailed analysis of the areas where the site falls short, and what can be done about it. (Up until a few days ago, the total size was 8.8MB, including a 3MB PNG image. Thanks to the Fershad’s work in highlighting this to the COP26 team, the image has now been replaced with a much smaller version.)

By understanding which elements of our design have the greatest impact on performance, we can gain an understanding of where some of our biggest carbon savings could lie, and begin to make trade-offs. The carbon budget might need to be different for every site — sites that require a lot of motion and interactive content, for instance, may inevitably use more resources. But perhaps for a simple web page like this we could aim for under 1g of carbon per page view? When we think about how many page views a site like COP26 would accumulate over the period of the conference, this could amount to significant savings.

Once we can identify where possible carbon savings lie, we can do something about them. Wholegrain Digital’s article “17 Ways to Make your Website More Energy Efficient” is a good place to start. I also recommend reading Sustainable Web Design by Tom Greenwood for a practical guide to holistically reducing the environmental impact of the sites we build. The website Sustainable Web Design has some excellent development resources.

As for convincing clients to buy into the idea of a carbon budget, using Core Web Vitals to kick off that conversation is a good place to start. Using tools like Lighthouse, we can see which aspects of our site have the most impact on performance and how Core Web Vitals are affected. Seeing the impact of that code on your clients’ site performance score (which can affect Google’s search ranking) might just be enough to convince them.

It would be great to see Google (and other industry-leading companies) lead the way on this and build carbon calculations into tools like Lighthouse. By putting that information front and center they could play an important role in empowering developers to make more environmentally-conscious decisions — and show that they’re putting their money where their mouth is. (There’s actually an open GitHub issue for this.) Perhaps we also need some kind of industry-wide certification, as explored in this article by Mike Gifford.

There’s much more we can do to improve the carbon footprint of our sites. It’s time for the web industry to heed this wake-up call. In the words of Greta Thunberg:

No one is too small to make a difference.

CSS-Tricks

, , , , ,

Websites We Like: MD Nichrome

Here’s a beautiful website: it’s a type specimen for Mass-Driver’s ever-so-lovely type family MD Nichrome. There’s a ton of nifty animations and graphics explaining all the features inside…

If you’re wondering how those animations work, they’re actually styled <video> elements.

There’s lots of great graphic design touches as well, such as how the letters below trail off and fade away…

That little bit of CSS is neat. It makes sure that each <h1> stays on a single line with white-space, then sets hidden overflow on them so the heading trails off. The fading is courtesy of a linear gradient that incorporates transparency. The gradient is actually a mask-image in this case. That’s a good reminder that CSS gradients are images generated by the browser.

h1 {   white-space: nowrap;   overflow: hidden;   -webkit-mask-image: linear-gradient(to right, black 75%, transparent); }

In the image above you can also see how Mass-Driver is advertising the OpenType features of the font. That’s stuff like fractions or alternate letters that gives your text superpowers. By default, these sections show what the feature is, but when you hover over them they do the following:

.element {   font-feature-setting: unset; }

I don’t think I’ve ever used unset before but this is a great place to use it—show what the feature looks like up front and then when you hover show what the default is. Smart stuff.

But the part that caught my eye—besides the kick ass typography—is the background. It’s made up of two parts: a shimmery animation that makes the page look like paper, and the gradient that’s stacked on top of it. And after digging around in DevTools I realized that shimmering effect is a PNG image where the background-position property moves the picture around slightly to animate it like a GIF. It’s hard to see in pictures, so here’s a copycat demo I made with the opacity turned off to make it easier to see:

See that lovely fuzziness? It gives the background a kind of… texture… that I haven’t seen for a long time, perhaps since around 2008 when everyone was trying to make buttons look like real, analog buttons on the web. Geoff covered the same sort of technique a while back where you can get a deep dive into how it works.

The other part of the design of this website is the gradient in the background. How are those so smooth? Well, Rutherford Craze, the designer behind this ingenious bit of web design, made a thread explaining how he got this effect to work in the browser. He created a gradients tool that lets you create a similar effect:

Rutherford writes:

Conventional CSS gradients plot a straight line through colour space, interpolating directly from the start to the end colour. This tool applies the principles of bézier curves, the basis of digital fonts, to this operation.

By introducing ‘control points’ along the gradient, you can more finely control the interpolation and produce a smoother end result. The tool then samples this ‘bézier gradient’ to produce a linear gradient you can work with in CSS.

What Rutherford is describing above is what’s known as the “Gray Dead Zone” of gradients, where often in a linear gradient there’s this gray color that forms in the middle.

Another small detail that I almost didn’t catch was the sticky navigation: when you first load the website you just see the logo with nothing else, but then as you scroll you’ll see the nav and it locks into place:

Notice how sticky positioning is also used later on to demonstrate the font’s glyphs.

CSS makes this sort of thing so easy. Declare sticky positioning on the element, then offset the stickiness if the element should start sticking at a certain spot.

.sticky-thing {   position: sticky;   top: 75px; }

Since they want you to focus on the letters first and not all the rest of the UI, it makes a ton of sense to put the navigation off to one side, only when you need it. And this makes the overall design feel incredibly focused and straightforward, barely worth commenting on at all perhaps, but when most websites are so full of distractions then I think it’s worth celebrating quiet websites like these.


The post Websites We Like: MD Nichrome appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, ,
[Top]

Static Site Generators vs. CMS-powered Websites: How to Keep Marketers and Devs Happy

(This is a sponsored post.)

Many developers love working with static site generators like Gatsby and Hugo. These powerful yet flexible systems help create beautiful websites using familiar tools like Markdown and React. Nearly every popular modern programming language has at least one actively developed, fully-featured static site generator.

Static site generators boast a number of advantages, including fast page loads. Quickly rendering web pages isn’t just a technical feat, it improves audience attraction, retention, and conversion. But as much as developers love these tools, marketers and other less technical end users may struggle with unfamiliar workflows and unclear processes.

The templates, easy automatic deploys, and convenient asset management provided by static site generators all free up developers to focus on creating more for their audiences to enjoy. However, while developers take the time to build and maintain static sites, it is the marketing teams that use them daily, creating and updating content. Unfortunately, many of the features that make static site generators awesome for developers make them frustrating to marketers.

Let’s explore some of the disadvantages of using a static site generator. Then, see how switching to a dynamic content management system (CMS) — especially one powered by a CRM (customer relationship management) platform — can make everyone happy, from developers to marketers to customers.

Static Site Generator Disadvantages

Developers and marketers typically thrive using different workflows. Marketers don’t usually want to learn Markdown just to write a blog post or update site copy — and they shouldn’t need to. 

Frankly, it isn’t reasonable to expect marketers to learn complex systems for everyday tasks like embedding graphs or adjusting image sizes just to complete simple tasks. Marketers should have tools that make it easier to create and circulate content, not more complicated.

Developers tend to dedicate most of their first week on a project to setting up a development environment and getting their local and staging tooling up and running. When a development team decides that a static site generator is the right tool, they also commit to either configuring and maintaining local development environments for each member of the marketing team or providing a build server to preview changes.

Both approaches have major downsides. When marketers change the site, they want to see their updates instantly. They don’t want to commit their changes to a Git repository then wait for a CI/CD pipeline to rebuild and redeploy the site every time. Local tooling enabling instant updates tends to be CLI-based and therefore inaccessible for less technical users.

This does not have to devolve into a prototypical development-versus-marketing power struggle. A dynamic website created with a next-generation tool like HubSpot’s CMS Hub can make everyone happy.

A New Generation of Content Management Systems

One reason developers hold static site generators in such high regard is the deficiency of the systems they replaced. Content management systems of the past were notorious for slow performance, security flaws, and poor user experiences for both developers and content creators. However, some of today’s CMS platforms have learned from these mistakes and deficiencies and incorporated the best static site generator features while developing their own key advantages.

A modern, CMS-based website gives developers the control they need to build the features their users demand while saving implementation time. Meanwhile, marketing teams can create content with familiar, web-based, what-you-see-is-what-you-get tools that integrate directly with existing data and software.

For further advantages, consider a CRM-powered solution, like HubSpot’s CMS Hub. Directly tied to your customer data, a CRM-powered site builder allows you to create unique and highly personalized user experiences, while also giving you greater visibility into the customer journey.

Content Management Systems Can Solve for Developers

Modern content management systems like CMS Hub allow developers to build sites locally with the tools and frameworks they prefer, then easily deploy to them their online accounts. Once deployed, marketers can create and edit content using drag-and-drop and visual design tools within the guardrails set by the developers. This gives both teams the flexibility they need and streamlines workflows. 

Solutions like CMS Hub also replace the need for unreliable plugins with powerful serverless functions. Serverless functions, which are written in JavaScript and use the NodeJS runtime, allow for more complex user interactions and dynamic experiences. Using these tools, developers can build out light web applications without ever configuring or managing a server. This elevates websites from static flyers to a modern, personalized customer experience without piling on excess developer work. 

While every content management system will have its advantages, CMS Hub also includes a built-in relational database, multi-language support, and the ability to build dynamic content and login pages based on CRM data. All features designed to make life easier for developers.

Modern CMS-Based Websites Make Marketers Happy, Too

Marketing teams can immediately take advantage of CMS features, especially when using a CRM-powered solution. They can add pages, edit copy, and even alter styling using a drag-and-drop editor, without needing help from a busy developer. This empowers the marketing team and reduces friction when making updates. It also reduces the volume of support requests that developers have to manage.

Marketers can also benefit from built-in tools for search engine optimization (SEO), A/B testing, and specialized analytics. In addition to standard information like page views, a CRM-powered website offers contact attribution reporting. This end-to-end measurement reveals which initiatives generate actual leads via the website. These leads then flow seamlessly into the CRM for the sales team to close deals.

CRM-powered websites also support highly customized experiences for site users. The CRM behind the website already holds the customer data. This data automatically synchronizes because it lives within one system as a single source of truth for both marketing pages and sales workflows. This default integration saves development teams time that they would otherwise spend building data pipelines.

Next Steps

Every situation is unique, and in some cases, a static site generator is the right decision. But if you are building a site for an organization and solving for the needs of developers and marketers, a modern CMS may be the way to go. 

Options like CMS Hub offer all the benefits of a content management system while coming close to matching static site generators’ marquee features: page load speed, simple deployment, and stout reliability. But don’t take my word for it. Create a free CMS Hub developer test account and take it for a test drive.


The post Static Site Generators vs. CMS-powered Websites: How to Keep Marketers and Devs Happy appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , , , , , ,
[Top]

Creating Powerful Websites with Serverless-Driven CMS Development

Choosing the right tools to build a website for your organization is essential, but it can be tough to find the right fit. Simple site builders like Wix and Squarespace are easy for marketers to use, but severely limit developers when it comes to customizing site functionality. WordPress is a more robust content management system (CMS), but it requires clunky plugins with infrequent updates and potential security issues

Other site-building tools, such as Gatsby or Hexo, are developer-friendly, but make it very challenging for content creators without technical backgrounds to make even simple updates on their own. These tools often don’t meet the needs of large creative teams running corporate websites.

But there is an option that solves for both audiences. HubSpot’s CMS Hub is a content management system powered by a full CRM Platform that empowers developers to build advanced functionality and marketers to make updates and publish content on their own.

One of the features CMS Hub offers developers is the ability to create serverless functions. These functions make it possible to enhance a website’s backend functionality with integrated plugins that are much easier to develop, deploy, and maintain than third-party WordPress plugins. 

Throughout this article, you’ll get a hands-on look at how HubSpot serverless functions help you build custom websites that clients love. To provide a super-quick preview of what is possible, we’ll fetch news data using GET functions that could be used to populate a dynamic webpage. You’ll need to know some JavaScript to follow along. 

HubSpot Serverless Functions

Serverless architecture enables developers to build and run applications and services without managing the server’s infrastructure. You don’t need to provision, scale, and maintain servers or install and manage databases to host and serve your web applications. When your business grows, it is much easier to scale.

HubSpot’s serverless functions are as powerful as WordPress plugins. They are capable of interacting with HubSpot’s CRM platform as well as integrating with third-party services through APIs. You can use serverless functions to enhance your site, for example:

  • Getting data and storing it in HubDB or the HubSpot CRM
  • Integrating your website with third-party services like Google Forms
  • Creating event registration systems
  • Submitting forms that send data to other services

The functions’ code is stored in the developer file system and is accessed from the Design Manager user interface (UI) or the command-line interface (CLI). You can use the CLI to generate and edit the code locally using your preferred local development tools then upload these changes to HubSpot.

To try the example serverless function in the next section, you need to have access to a CMS Hub Enterprise account or sign up for a free developer testing account. We’ll deploy serverless functions into a site created based on the CMS Boilerplate.

(If you are not familiar with HubSpot development, you may want to check out the quick start guide before following along with the examples below.)

Fetching News Data Using GET Requests

Let’s start by implementing a serverless function that sends a GET request to a third-party REST API to fetch the latest news data using the Axios client. This API searches for online news articles that mention the keyword “HubSpot.”

Note: We’ll be using a third-party API available from NewsAPI.org to retrieve news data, so you first need to register for their API key.

APIs that require authentication or use API keys are not safe for a website’s frontend as they expose your credentials. Serverless functions are a good solution as an intermediary, keeping your credentials secret.

Head over to a CLI and run the following commands:

cd local-cms-dev mkdir myfunctions hs create function 

First, we navigate to our local CMS project, and we call the hs create function command to generate a simple boilerplate function.

You’ll be prompted for some information about your functions, such as:

  • Name of the folder where your function will be created. Enter myfunctions/getnews.
  • Name of the JavaScript file for your function. Enter getnews.
  • Select the HTTP method for the endpoint. Select GET.
  • Path portion of the URL created for the function. Enter getnews.

You should get a message saying that a function for the endpoint “/_hcms/API/getnews” has been created. This means, once uploaded, our function will be available from the /_hcms/API/getnews endpoint. 

Before uploading the function, let’s first implement our desired functionality.

Open the myfunctions\getnews.function\getnews.js file. You’ll find some boilerplate code for a serverless function that sends a GET request to the HubSpot search API. Remove the boilerplate code and leave only the following updated code:

const axios = require('axios'); const API_KEY = '<YOUR_API_KEY_HERE>';  exports.main = async (_, sendResponse) => {     };

Note that you should normally add your API key via the command-line interface hs secrets command, but adding it here is sufficient for the purpose of demonstrating the function.

We require the Axios library to send HTTP requests, and we export a main function that HubSpot executes when a request is made to the associated endpoint. We also define an API_KEY variable that holds the API key from the news API.

Next, inside the body of the main function, add the following code:

const response = await axios.get(`https://newsapi.org/v2/everything?q=HubSpot&sortBy=popularity&apiKey=$  {API_KEY}`); sendResponse({ body: { response: response.data }, statusCode: 200 });

We call Axios to send a GET request to the API endpoint, then we call the sendResponse method to send the fetched data back to the client. We could call this API directly from the frontend code, but we would need to expose our API key, which should be secret. Thanks to the serverless function, fetching data happens on the server side, so we don’t have to expose the secret.

Finally, run the following command to upload your function:

hs upload myfunctions myfunctions

This command uploads files from the myfunctions local folder to a myfunctions folder (that will be created) in your account’s Design Manager.

Finally, run the method by visiting the /_hcms/API/getnews endpoint with your web browser. In our case, we need to visit this link. Here, you should see a list of news articles about HubSpot – albeit without any front-end design. 

While it is beyond the scope of this article, our next step would be to take the data from the NewsAPI and create a template that would allow us to output the news results onto a dynamic webpage. And with this, we’ll have a place where anyone can quickly catch up on all the latest news mentioning HubSpot or any other keyword you decide to include.  

Next Steps

When you need a small brochure-based website and won’t be making many updates, any CMS will do. However, when you are looking to create advanced digital experiences to grow your organization, HubSpot’s CMS Hub offers the functionality and flexibility you need. Plus, you can work with your preferred tools and modern workflows such as CLIs, integrated development environments (IDEs), and GitHub. 

Hopefully, this article has provided an initial glimpse of what is possible with HubSpot’s serverless functions. But don’t stop here, dive in and experiment with adding custom functionality to your own HubSpot-powered website. Your imagination is the limit. Sign up for a free developer test account to get started.

Further reading:


Ahmed Bouchefra is a developer and technical author with a BAC + 5 diploma in software development. Ahmed builds apps and authors technical content about JavaScript, Angular, Ionic, and more.


The post Creating Powerful Websites with Serverless-Driven CMS Development appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , ,
[Top]

Recipe websites, data modeling, and user experience

Simeon Griggs with some nice UX ideas for a recipe website:

  • No math. Swap between units and adjust servings on-the-fly.
  • Offer alternative ingredients.
  • Re-list the ingredient amounts when they’re referenced in the instructions.

I totally agree, especially on that last one:

Of all our improvements I think this is my favourite.

A typical recipe layout contains ingredients with amounts at the start. Then, a bullet point list of instructions to perform the method.

The method though typically does not reference those amounts again, so if you don’t prepare all your amounts ahead of time (which is what you’re probably supposed to do but come on who does that) you’ll have to keep scanning back and forward.

Part of what makes this stuff possible is how you set up the data model. For example, an ingredient might be an Array instead of a String so that you’re set up for offering alternatives right out of the gate.

Direct Link to ArticlePermalink


The post Recipe websites, data modeling, and user experience appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , , ,
[Top]

Some Recent Videos About Websites That Are Pretty Good

Here’s a little hodgepodge of videos I’ve recently bookmarked (and watched). I couldn’t decide if each one of them should be a separate blog post or if I should do this combined list post thing. If I had a lot more to say about each video I would have split them off, but I went with the combined post and fewer words here. Let me know in the comments if you have a preference on that kind of thing.

Here’s Tom Scott explaining why the web is such a mess

Cookies. It all cookies fault. Kinda. Also humans.

This is the same Tom that did that super neat video that updated it’s own title with the view count.

I don’t know this person’s name but I appreciated how it gets the details right in this recreation of the Discord sidebar

Except the fact that the :hover was on the <li> itself rather than a link that went somewhere sensible, but hey, I guess it’s slightly better than the actual Discord markup where it’s <div class="listItem_">.

Heydon gets all weird about progressive enhancment

I can’t embed it here because, even though it looks like Heydon switched over to Vimeo rather than just straight up <video> tags, the privacy settings have it locked to briefs.video only.

I liked the point about “the basic layout is not a broken layout,” except, doesn’t it seem like in that exact case it wouldn’t matter if you wrapped the grid-template-rows in a @supports or not? I love that @supports is a thing, and even more so now that we’ve passed the awkward years where @supports itself didn’t have full browser support, but I don’t find myself reaching for it that much, as it’s only really useful if you need to do something different than “just let it not work,” which I don’t find terribly common.

Houssein Djirdeh and Jason Miller get into “modern JavaScript”

We’ve gotta be so careful about compiled code. There is an example where one line of JavaScript gets compiled into 7000 bytes, which is bigger and far slower than intended. Taking care of older browsers when you have a significant number of users using that old browser is a really great thing, but you might be surprised at the browser support of “modern JavaScript” and find you are compiling more than you need to.

The kicker is that you only really control what you write, but probably most of what you ship is third-party. That means npm, which is absolutely loaded with very non-modern JavaScript. The sweet spot, they say, is calling ES 2017 the compile target in general. If you need even older support, use the ol’ differential serving trick.

There’s a blog version of this video, too.

Jessica Chan challenges William Candillon to a CSSBattle

Like literally CSSBattle, the website.

They go back and forth trying to figure out how to make this little spiky virus-looking thing. I totally relate to their approaches! Neither of them are like amazingly clever with either the HTML or CSS — they just try to get it done. That’s why I could never get into CSSBattle myself. I appreciate people’s trickery (duh), but my actual CSS writing style is almost like verbose-on-purpose.


The post Some Recent Videos About Websites That Are Pretty Good appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , , , ,
[Top]

Creating websites with prefers-reduced-data

Spoiler alert: There is no support for it yet. But it is defined in the Media Queries Level 5 spec that includes other recent, but more familiar user preference features, like prefers-color-scheme and prefers-reduced-motion.

The Polypane blog goes into incredible depth on prefers-reduced-data, especially for something that we have yet to see in the wild. That’s actually what makes the Polypane team an ideal voice on the subject. It’s product is a browser that is able to emulate the feature behind a Chromium flag.

At the same time, it’s worth noting that the spec calls out two significant potential issues with this feature in its current state:

  • It may be an undesired source of fingerprinting, with a bias towards low income with limited data. 
  • This feature is an early draft, and the CSS-WG does not consider it ready for shipping in production.

But that’s not to say we can’t start getting acquainted with it. Here’s how it works:

@media (prefers-reduced-data: reduced) {   /* Stuff for reduced data preferences */ }  @media (prefers-reduced-data: no-preference) {   /* Stuff for no data preferences */ }

What I appreciate from this post is the wealth of possible use cases it lists. Allow me to summarize:

  • Conditionally load fonts. As in, make a @font-face declaration then call the font on the body, once for users with no-preference to get the custom font, and again for users with reduced to get a lighter stack.
  • Background images. Have you ever used a giant splash image as the background for some full-width hero component? Maybe that can be served just to folks who have no-preference while those with reduced get either a smaller variation or no image at all.
  • Smaller images in HTML. This is clever because remember that we have the media attribute on the <source> element. So, we can instruct browsers to use certain images when working with <picture>, a la: <source srcset="small.jpg" media="(prefers-reduced-data: reduce)" />.
  • Conditionally preload and autoplay videos. Just as we can work with this feature in HTML, we can use it in JavaScript, too, by using window.matchMedia('(prefers-reduced-data: no-preference)').matches to set autoplay and preload attributes on a video based on data preferences.
  • Ditch infinite scrolling. I’d generally ditch this pattern in the first place, but we can certainly disable it so users who prefer reduced data aren’t force-fed more content (and thus, more data) just by reaching the end of a page.

That’s not a definitive list of ideas, of course! We talk all the time about serving the right assets to the right people at the right time and this media feature is a great tool to help us do that in certain contexts. Think also of:

  • Providing low-res versions of downloaded assets (e.g. PDFs)
  • Linking to certain sites or pages that have heavy experiences
  • Conditionally loading entire scripts, stylesheets, or libraries based on preference
  • Probably a gazillion other and more clever things…

And this advice is golden:

Like prefers-reduced-motion, it’s good to think of the prefers-reduced-data: reduce option as the default option: people get the lean, fast experience, and only when they indicate no-preference, we send them more data. That way, older browser that don’t support the media query get the lean experience by default.

Yep. The same sort of idea as “mobile-first” responsive design: start by designing for reduced data and then enhance as we scale up.

Direct Link to ArticlePermalink


The post Creating websites with prefers-reduced-data appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, ,
[Top]

Websites We Like: Whimsical

Whimsical is an app that lets you create flowcharts, wireframes, and mind maps but it was only earlier today that I spotted just how great the website is — especially the product pages. Check out this page where they describe how to use the Mind Maps feature where you can use the product right there on the marketing site.

Neat, huh? This is all done through the power of the <canvas> element. You could make something like this with SVG for sure but there’s always a blurry line between picking SVG and canvas.

However, in terms of design, I love this idea of the advertisement being the product. And I also love cutting out all the usual sign-up nonsense to show folks the value of the app. Most products make you sign up and go through onboarding before you can see the value of the product. But that’s just not the case here; the ad is the product!

Also, I just love the design of this thing. Each product feature has its own theme, which makes the product demos pop a bit more as you look around. It’s a small detail but makes me want to explore the rest of the site to see what other fancy UI trinkets are lying around.

I also like also being able to jump straight into a working example of a wireframe. There’s no marketing spiel about how revolutionary the app is or how it’ll change the art of mind maps forever. Everything gets out of the way to show you the product, first and foremost.

But! Going back to the navigation for a sec: choosing not to label those icons is an interesting decision. It’s lovely, but what does each icon mean? This is covered in a post Chris wrote a while back when he asked: Are icons content? That said, the argument about whether or not to label icons has been going on for decades in software design. Jef Raskin, one of the designers of the original Macintosh back in the 1980s, wrote a great book called The Humane Interface where he argues that we should never leave icons unlabelled. Perhaps that’s a bit much, but in this case, I don’t think it would hurt to label these icons since they’re product-specific and mind map icons aren’t something we see every day.

Whimsical’s typography is interesting, too! they’re using DIN Next which feels a little at odds with the visual design, at least to me. DIN Next is the kind of typeface that gets lost in the background, designed to stand back and display fonts take center stage:

But I think the font’s success is carried by the buck wild visual design — the squiggly lines, the floating circles and moon shapes that are found everywhere in the UI. Then again, perhaps you don’t want the typeface to stick out when your UI is so visually loud, and I mean that in a good way.

The trick to designing an interface like this is making sure color accessibility is taken into consideration though. Stacie Arellano wrote about why color contrast is so important a while back:

You can mathematically know if two colors have enough contrast between them. 

The W3C has a document called Web Content Accessibility Guidelines (WCAG) 2.1 that covers successful contrast guidelines. Before we get to the math, we need to know what contrast ratio scores we are aiming to meet or exceed. To get a passing grade (AA), the contrast ratio is 4.5:1 for most body text and 3:1 for larger text.

I’m not going to double check the numbers here for Whimsical, but it’s worth keeping an eye on… especially when a UI has a lot of white text on bright and colorful backgrounds. I’ve managed to mess this up more than a few times and it’s an easy thing to trip up on. But if folks can’t read the text in your UI, that’s a big problem.


Anyway, this site for the Whimsical product is a breath of fresh air. It’s visually striking and shows that communicating a product’s value and features can be done with show-and-tell instead of tell-and-tell.

Which leads me to ask you a question: Is there a website you’ve recently visited that caught your eye?


The post Websites We Like: Whimsical appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, ,
[Top]

Thinking About Power Usage and Websites

Gerry McGovern asked if I had any insight into energy consumption and websites. He has a book, after all, about the digital costs on the planet. He was wondering about the specifics of web tech, like…

If you do this in HTML it will consume 3× energy but if you do it in JavaScript it will consume 10×.

I would think if you really looked, and knew exactly how to measure it, you could find examples like that. Say I wanted to move an element across the screen. If I wrote a setInterval loop in JavaScript that incremented the left position on the relative-positioned element by one millisecond, I’m 99% sure that takes more literal electricity to do than if you were to do a CSS @keyframes animation over the same time where you changed the transform: translateX() value. In that example, usually, we’re thinking about performance moreso than energy consumption, but that’s interesting right away: does good performance map to lower energy usage? Probably.

Researches have looked into this.

We discover a statistically significant negative correlation between performance scores and the energy consumption of mobile web apps (with medium to large effect sizes), implying that an increase of the performance score tend to lead to a decrease of energy consumption.

They were testing mobile web apps on Android using Lighthouse scores. I can guess that maps pretty well to other platforms and other performance metrics.

I’m glad the research so far maps to what I would logically expect to be true. Things that lead to poor performance are things that take energy. Imagine images. You’ll be dinged on performance scores for serving too large or unoptimized images. Imagine the performance implications of that. There are two images sitting on a server, a large one and a small one. Which one takes more electricity to travel to some user’s computer? The large one. Which one takes more processing power to parse and display? The large one. Which one occupies more memory (which uses electricity) for the duration of it’s life on screen? The large one.

The less across the network, the less electricity.

The less your browser has to do, the less electricity.

Some ad that auto-refreshes itself every few seconds? Not only is it annoying, but it’s bandwidth-wasteful and thus wasteful with electricity. Whenever you have to resort to polling (i.e. making a network request over and over) rather than something event-based like web sockets? That’s using electricity that you may not have needed to use.

We know that CDNs are good for performance too. Rather than a file (like an image) needing to travel across the world, it comes from a server much geographically closer on a server designed for that job. This is where things get a little more murky to me.

With performance as our goal: objective achieved. With low-energy consumption as our goal, are we there?

It has been studied, but unfortunately, I can’t tell what the conclusion is from the abstract alone. In my mind, things are complicated by the fact that servers around the world are storing copies of these assets, and when the assets change, it’s not just one server where they update, but again, servers around the world. There has got to be a balance between the propagation and duplicative storage as far as the savings that would be realized by the efficiency of saving requests.

Speaking of storage efficiency, I’m certain that storage just sitting on disk takes a lot less electricity than files being sent over networks — but it still has a cost. Say you saved a copy of every file every time you changed it. Say you saved a complete copy of your website every time you deployed it. Useful? Sure. Does that cost electricity? It must. There must be some balance to strike there.

Gerry was asking me about particular technologies though. I can think of another big deal thing in CSS land: dark mode! Yet again, it’s been studied. Dark mode saves power.

Dark Mode can indeed reduce the display power draw by up to 58.5% at full brightness for the set of popular Android apps that we tested! In terms of whole phone battery drain reduction, that translates into 5.6% to 44.7% savings at full brightness and 1.8% to 23.5% savings at 38% brightness.

And what about comparing technologies? I suspect it’s far more about what that technology (or language) is doing than the language itself. For example, I can build a little area that opens and closes in HTML with a <details> element. Is that more energy-efficient than creating that area by attaching a click handler on a button that toggles the class of an element that visually opens and closes it? I kinda doubt it. I’d bet the electricity being used in the re-paint/re-render steps that the browser is doing and the languages behind it are less relevant. And yet! If I made the browser download a 50 KB JavaScript library just to implement my little open/close element, then yes, it does matter, and the JavaScript version is less efficient.

In that way, just as good performance generally maps to less energy consumption, I’d bet that adhering to the rule of least power generally maps to less energy consumption as well.

Sick of me guessing at stuff? Fair enough.

Jack Lenox’s article “How Improving Website Performance Can Help Save The Planet” on Smashing is a better deep dive. He points to websites that will test your site. Website Carbon Calculator is one example and it states:

Calculating the carbon emissions of website is somewhat of a challenge, but using five key pieces of data we can make a pretty good estimate:

1. Data transfer over the wire
2. Energy intensity of web data
3. Energy source used by the data centre
4. Carbon intensity of electricity
5. Website traffic

The testing code is open source.


The post Thinking About Power Usage and Websites appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , ,
[Top]

Using BugHerd to Track Visual Feedback on Websites

BugHerd is about collecting visual feedback for websites.

If you’re like me, you’re constantly looking at your own websites and you’re constantly critiquing them. I think that’s healthy. Nothing gets better if you look at your own work and consider it perfectly finished. This is where BugHerd shines. With BugHerd, anytime you have one of those little “uh oh this area is a little rough” moments while looking at your site, you can log it to be dealt with.

Let’s take a look at a workflow like that. I’m going to assume you’ve signed up for a BugHerd account (if not grab a free trial here) and either installed the script on your site or have installed the browser extension and are using that.

I’ve done that for this very site. So now I’m looking at a page like our Archives Page, and I spot some stuff that is a little off.

I’ve taken a screenshot and circled the things that I think are visually off:

  1. The “Top Tags” and dropdown arrow are pretty far separated with nothing much connecting them. Maybe dropdowns like that should have a background or border to make that more clear.
  2. There is a weird shadow in the middle of the bottom line.

With BugHerd, I can act upon that stuff immediately. Rather than some janky workflow involving manual screenshots and opening tickets on some other unrelated website, I can do it right from the site itself.

  1. I open the BugHerd sidebar
  2. I click the green + button
  3. Select the element around where I want to give the visual feedback
  4. Enter the details of the bug

Their help video does a great job of showing this.

Here’s me logging one of those bugs I found:

Now, the BugHerd website becomes my dashboard for dealing with visual bugs. This unlocks a continual cycle of polish that that is how great websites get great!

Note the kanban board setup, which is always my prefered way to work on any project. Cards are things that need to be worked on and there are columns for cards that aren’t started, started, and finished. Perhaps your team works another way though? Maybe you have a few more columns you generally kanban with, or you name them in a specific way? That’s totally customizable in BugHerd.

I love that BugHerd itself is customizable, but at a higher level, the entire workflow is customizable and that’s even better.

  • I can set up BugHerd just for myself and use it for visual improvement work on my own projects
  • I can set up BugHerd for just the design team and we can use it among ourselves to track visual issues and get them fixed.
  • I can set up BugHerd for the entire company, so everyone feels empowered to call out visual rough spots.
  • I can set up BugHerd for clients, if I’m a freelancer or agency worker, so that the clients themselves can use it to report visual feedback.
  • I can open up BugHerd wide open so that guests of these websites can use it to report visual problems.

Check out this example of a design team with core members and guests and their preferred workflow setup:

It’s hard to imagine a better dedicated tool than BugHerd for visual feedback.

The post Using BugHerd to Track Visual Feedback on Websites appeared first on CSS-Tricks.

CSS-Tricks

, , , , ,
[Top]