Your website’s only as strong as the weakest device you’ve tested it on.
It’s no substitute for testing with real devices, but the “device wall” view in this Chrome plug-in is a nifty way of getting an overview of a site’s responsiveness at a glance.
This looks like a useful tool, not just for testing locally-hosted sites (say, at a device lab), but also for making locally-hosted sites run on HTTPS so you can test service workers.
Excellent and practical advice for before, during, and after research sessions and usability tests.
Smart use of attribute selectors in CSS to catch mistakes in HTML.
Some interesting insights from usability and accessibility testing at the Co-op.
We used ‘nesting’ to reduce the amount of information on the page when the user first reaches it. When the user chooses an option, we ask for any other details at that point rather than having all the questions on the page at once.
A little tool for testing common form issues.
- Did we remember to give every input a label? (No, placeholders are not an adequate replacement)?
- Do our labels’ for attributes match our inputs’ ids?
- Did we take advantage of the url, email, and password input types, or did we forget and just use text?
- Are our required fields marked as such?
Ire rounds up a bunch of tools you can use to test accessibility, from dev tools to Tenon.
Here’s an interesting metric for measuring performance: take the overall page weight of a URL and divide it by the file size of the screenshot of that URL.
Alex runs through the features that a progressive web app must have, should have, and would be nice to have.
In general, installability criteria are tightening. Today’s Good-To-Haves may become part of tomorrow’s baseline. The opposite is unlikely because at least one major browser has made a strong commitment to tightening up the rules for installability.
Right now, this is in the nice-to-have category:
Mobile-friendly, not mobile-only.
Personally, I’d put that in the must-have category, and not just for progressive web apps.
Anyway, read on for some advice on testing and tooling when it comes to evaluating progressive web apps.
Some interesting outcomes from testing gov.uk with blind users of touchscreen devices:
Rather than reading out the hierarchy of the page, some of the users navigated by moving their finger around to ‘discover’ content.
This was really interesting - traditionally good structure for screen readers is about order and hierarchy. But for these users, the physical placement on the screen was also really important (just as it is for sighted users).
There’s a lot I disagree with here. I don’t think this pattern library process is very elegant or scalable, and it certainly wouldn’t work for me.
But I’m still linking to it. Why? Because I think it’s absolutely wonderful that people share their processes like this. It doesn’t matter one whit whether or not it would work for me.
Frontend development may have gotten a lot more complicated, but the simple premise of sharing what you’ve learned hasn’t.
I couldn’t agree more!
The book by Destiny Montague and Lara Hogan is online for free with a Creative Commons licence:
Learn to build a device lab with advice on purchasing, power solutions, and much more in this handy pocket guide.
Do you live in Stockholm? If so, you’ve got a device lab you can visit.
So feel free to drop by and test your responsive/mobile designs.
This might be the most remote open device lab yet. Looks pretty great.
Regular expressions are my kryptonite. I’m rubbish at them and I can never keep the vocabulary in me head.
Mark recommended this tool so I’m going to give it a go the next time I have to resort to regex.
Lara and her colleague Destiny Montague have published a ridiculously useful handbook on setting up a device lab. For such a small book, it’s surprisingly packed with information.
A tool for getting instant visual feedback on your nth-child selectors. Considering that the way I figure out nth-child selectors is to try randomly changing numbers until it works, this should be quite useful for me.
More thoughts on the lack of a performance culture, prompted by the existence of Facebook Instant:
In my experience, the biggest barrier to a high-performance web is this: the means of production are far removed from the means of delivery. It’s hard to feel the performance impact of your decisions when you’re sitting on a T3 line in front of a 30 inch monitor. And even if you test on real devices (as you should), you’re probably doing it on a fast wifi network, not a spotty 3G connection. For most of us, even the ones I would describe as pro-performance, everything in the contemporary web design production pipeline works against the very focus required to keep the web fast.