Tag: Websites

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

, , , , ,

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]

Notion-Powered Websites

I’m a big fan of Notion, as you likely know from previous coverage and recent video. It’s always interesting to see what other people do with Notion, and even how Notion uses Notion.

I’d say most usage of Notion is private and internal, but any page on Notion can be totally public with the flip of a switch. We do that with some stuff like our post ideas page and here’s a simple camping checklist I made for myself.

That’s pretty rad. You could use that for lots of business-things you might otherwise literally build a website to do. Maybe a public product roadmap, a job posting, a press release an announcement…

But it’s not quite a website. You don’t get a custom domain name. You don’t have any analytics on it. You’re limited by the exact feature set of Notion.

People have been trying to extract the data out of Notion and essentially use it as a CMS for a while now…

But all those ways are, ya know, a decent amount of effort.

Stephen Ou recently showed me a pretty cool idea he has called Fruition. It’s entirely free, and also a bit of effort to set up, but once you’re done, you have your own domain name that hosts a Notion page and gives you some control over it (like putting in fonts and scripts and such).

It’s very clever in that it uses Cloudflare Workers to do all the heavy lifting.

This is probably the easiest-to-manage website ever. Just open Notion, change stuff, done.

Stephen admits Fruition is somewhat complex to set up. If you’re looking for something easier and perhaps more flexible, check out Super.

Actual neumorphism in the wild!

I would note that none of these things are official Notion products or affiliates of it in any way. Honestly, they all make me a little nervous in that they could break if Notion ever decides they don’t care for the product to be used this way. I also feel like Notion has been saying an API is something they’d like to offer for a while. That will be the real answer to all this and there will be a proliferation of third-party products once we have it.

The post Notion-Powered Websites appeared first on CSS-Tricks.

CSS-Tricks

,
[Top]

How Many Websites Should We Build?

Someone emailed me:

What approach to building a site should I take?

  1. Build a single responsive website
  2. Build a site on a single domain, but detect mobile, and render a separate mobile site
  3. Build a separate mobile site on a subdomain

It’s funny how quickly huge industry-defining conversations fade from view. This was probably the biggest question in web design and development1 this past decade, and we came up with an answer: It’s #1, you should build a responsive website. Any other answer and you’re building multiple websites and the pain from that comes from essentially doubling the workload, splitting teams, communication problems across those teams, inconsistencies across the sites, and an iceberg of other pain points this industry has struggled with for ages.

But, the web is a big place.

This emailer specifically mentioned imdb.com as their example. IMDB is an absolutely massive site with a large team (they are owned by Amazon) and lots of money flying around. If the IMDB team decides they would be better off building multiple websites, well that’s their business. They’ve got the resources to do whatever the hell they want.

The post How Many Websites Should We Build? appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

We asked web developers we admire: “What about building websites has you interested this year?”

For the first time ever here on CSS-Tricks, we’re going to do an end-of-year series of posts. Like an Advent calendar riff, only look at us, we’re beating the Advent calendar rush! We’ll be publishing several articles a day from a variety of web developers we look up to, where gave them all the same prompt:

What about building websites has you interested this year?

We’re aiming for a bit of self-reflection and real honesty. As in, not what you think you should care about or hot takes on current trends, but something that has quite literally got you thinking. Our hope is that all put together, the series paints an interesting picture of where we are and where we’re going in the web development industry.

We didn’t ask people for their future predictions directly. Our hope is that the future is glimpsable through seeing what is commanding developer attention. I mention that as this series take some inspiration from NeimanLab’s series that run each year (e.g. 2019, 2018, 2017…) which directly asks for people’s predictions about journalism. Maybe we’ll try that one year!

Automattic has a been a wonderful partner to us for a while now, and so I’m using this series as another way to thank them for that. Automattic are the makers of WordPress.com and big contributors to WordPress itself, which this site runs on, and make premium plugins like WooCommerce and Jetpack, which we also use.

Stay tuned here on the blog for all the wonderful thoughts from developers we’ll be publishing this week (hey even RSS is still cool I heard) or bookmark the homepage for the series.

The post We asked web developers we admire: “What about building websites has you interested this year?” appeared first on CSS-Tricks.

CSS-Tricks

, , , , , , , , ,
[Top]

Location, Privilege and Performant Websites

Here’s a wonderful reminder from Stephanie Stimac about web performance. She writes about a recent experience of moving to an area with an unreliable network and how this caused problems for her as she tried to figure out what was happening during a power blackout:

Assuming all of your customers are living the same life, with the same privilege, with the same access to fast internet and data is the quickest way to ensure you’re excluding some of them and not providing the same level of service the rest get. It’s most likely not even happening intentionally, bias is inherent in us all in some way or another. Bias based on location is something I hadn’t considered before my experience on a subpar network due to where I live.

But if you’re providing a service or utility that is essential to a large portion of your community, it’s important to take a step back and assess your user experience from a different perspective.

Stephanie also makes note of how NPR has a text-only version of their website so that it’s still possible to access information on the worst possible network connections. CNN does something quite similar.

And doesn’t this go beyond web performance? At the core, this is an accessibility issue as well and yet another example of how hard it is to make accessible sites.

Direct Link to ArticlePermalink

The post Location, Privilege and Performant Websites appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]