Tag: Websites

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

, , , , ,

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]

Why Are Accessible Websites so Hard to Build?

I was chatting with some front-end folks the other day about why so many companies struggle at making accessible websites. Why are accessible websites so hard to build? We learn about HTML, we make sure things are semantic and — voila! @— we have an accessible website. During the course of conversation, someone mentioned the Domino’s pizza legal case, which is perhaps the most public example of a company being sued because of a lack of accessibility.

Here’s an interesting tidbit from that link:

According to CNBC, the number of lawsuits over inaccessible websites jumped 58 percent last year over 2017, to more than 2,200.

Inaccessible websites are not just a consideration for designers and engineers but a serious problem for a company’s legal team as well. Thankfully, it seems more of these cases will be brought to trial and (my personal hope is) this will get folks to care more about semantics and front-end development best practices. Although I’d like to think that companies would do what’s best for the web and make websites that meet the baseline requirements without a legal threat, we absolutely need to make inaccessible websites illegal for folks to really pay attention to this issue.

However! I also worry about attributing what might simply be a lack of knowledge to malice. I reckon a lot of websites have bad accessibility not because folks don’t care, but because they don’t know there’s an issue in the first place. As my conversation with front-end engineers progressed, I realized that the reason accessibility isn’t tackled seriously probably doesn’t have anything to do with bandwidth, or experience, or money.

I reckon the problem is that the accessibility of a website can be invisibly and silently broken.

Here’s an example: when developing a site, JavaScript errors are probably going to be caught because everything breaks if something goes wrong. And CSS bugs are going to get caught because something will look off. But the accessibility or performance of a website can go from okay to terrible overnight and with no warning whatsoever. Yhe only way to fix these invisibly broken things is to first make them visible.

So, here’s an idea: what if our text editors caught accessibility issues and showed them to us during development? It could look something like this:

An example of how performance and accessibility issues might be flagged in VS Code whilst you type.

I’m sure there are a ton of other ways we can make accessibility issues more public and visible. There are tools such as Lighthouse and browser extensions that are already out there, but making accessibility (and even performance, another silent fail) a part of our minute-to-minute workflow ensures that we can’t ignore it. Something like this would encourage us to learn about the problems, give us links to potential solutions, and encourage us all to care for a relatively misunderstood part of front-end development.

The post Why Are Accessible Websites so Hard to Build? appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Weekly Platform News: CSS column-span Property, ADA applies to Websites, Auto-generated Image Descriptions

In this week’s roundup: multi-column layouts gain wide support, the ADA means more A11y for retailers, and Google is doing something about all the empty image alt attributes in the wild.

The CSS column-span property will soon be widely supported

The CSS column-span property, which has been supported in Chrome and Safari since 2010 (and IE since 2012), is finally coming to Firefox in version 71 (in December).

This feature enables elements that span across all columns in a multiple-column layout. In the following demo, the headings span across both columns.

article {   column-count: 2; }  h2 {   column-span: all; }

See the Pen
Demo of CSS column-span: all
by Šime Vidas (@simevidas)
on CodePen.

(via Ting-Yu Lin)

The Americans with Disabilities Act applies to websites

In the United States, the Americans with Disabilities Act (ADA) applies to websites, which means that people can sue retailers if their websites are not accessible.

Domino’s Pizza’s appeal was recently turned down by the Supreme Court, so the lawsuit against them for failing to make their website accessible to screen reader users will now resume in district court.

Guillermo Robles, who is blind, filed suit in Los Angeles three years ago and complained he had been unable to order a pizza online because the Domino’s website lacked the software that would allow him to communicate. He cited the ADA, which guarantees to people with a disability “full and equal enjoyment of the goods and services … of any place of public accommodations.”

(via David G. Savage)

Google announces automatically generated image descriptions for Chrome

When used with the VoiceOver screen reader, Chrome can now automatically generate image descriptions for images that do not have proper alt text (<img alt> attribute). Google has already created more than 10 million image descriptions, but they are not meant to replace alt text written by humans.

Image descriptions automatically generated by a computer aren’t as good as those written by a human who can include additional context, but they can be accurate and helpful.

This new accessibility feature, called “Accessibility Image Descriptions,” may not be enabled by default in your version of Chrome, but you can enable it manually on the chrome://flags page.

(via Dominic Mazzoni)

More news…

Read even more news in my weekly Sunday issue that can be delivered to you via email every Monday morning.

More News →

The post Weekly Platform News: CSS column-span Property, ADA applies to Websites, Auto-generated Image Descriptions appeared first on CSS-Tricks.

CSS-Tricks

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