The other day, Frances Berriman—who coined the term “Progressive Web App”—wrote a bit about how she came up with that name. In it she clearly points out that the name has become a little problematic in dev circles
Browse by Tag: Web Development
Kelly and I are in the process of selling our (beautiful) home and I have been amazed at how difficult it’s been for our agents to break up the listing description into paragraphs, especially on Zillow. After a ton of trial and error—after all, I wasn’t gonna let poor software design trump readability—I found a solution.
TLDR; Insert a blank line between the paragraphs and put “ ” (that’s a space followed by a tab) on that line.
User experience encompasses more than just the interface. Download speed, render performance, and the cost of accessing a site are often overlooked areas when it comes to the practice of UX, but they all affect how users experience what we build on the Web.
For a while now I’ve been beating the “empathy” drum (notes), trying to get folks in our industry to understand the importance of creating connections with the people for whom we build software, websites, etc. After all, we design and build tools to solve the needs of actual people, not some generic “user”.
A while back GogOm reported on how Facebook’s decision to autoplay videos led to a 60% increase in mobile data usage. It was a business decision with the intent of increasing engagement, but it was a bad decision from a user experience. It’s a tax on users and they weren’t to happy about it.
You may be wondering Why is this a bad thing for users? They want to see videos, so we’re just giving them what they want. Well, let me share a little story.
I’ll level with you: I used to think I wanted variables in CSS.
As a programmer, I love the idea of being able to abstract reusable bits like colors, border widths, font sizes, and the like to obviously named variables. It’s a far more DRY approach and makes maintenance far easier.
In case you missed it, yesterday Pierre Far updated Google’s Webmaster Guidelines. In his post, Pierre lays out their case for progressive enhancement:
Just like modern browsers, our rendering engine might not support all of the technologies a page uses. Make sure your web design adheres to the principles of progressive enhancement as this helps our systems (and a wider range of browsers) see usable content and basic functionality when certain web design features are not yet supported.
Earlier today, Stuart Langridge—who I worked with on WaSP’s DOM Scripting Task Force and have the utmost respect for—published a blog response to my last post. In it, he made some good points I wanted to highlight, but he also misunderstood one thing I said and managed to avoid addressing the core of my argument. As comments aren’t enabled on his site, I thought I’d respond here.