Select Page

Category: Link

Prototypes and production

There’s an interesting distinction that Jeremy Keith defines between prototype code and production code in this post and I’ve been thinking about it all week: …every so often, we use the materials of front-end development—HTML, CSS, and JavaScript—to produce something that isn’t intended for production. I’m talking about prototyping. What’s interesting is that—when it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed. If that means sacrificing semantics or performance, then so be it. If I’m building a prototype and I find myself thinking “now, what’s the right class name for this component?”, then I know I’m in the wrong mindset. That question might be valid for production code, but it’s a waste of time for prototypes. I love the way that Jeremy phrases all of this and how he describes that these two environments require entirely separate mindsets. When prototyping, for instance, we can probably overlook optimizing for accessibility or performance and even let our CSS standards slip in order to get something in the browser and test it as quickly as possible. Earlier this year, I echoed some of the same thoughts when I wrote a little bit about prototyping in the browser: I reckon that the first time a designer and/or front-end developer writes code, it should never be in a production environment. Having the leeway and...

Read More

The Software We Pay For

We did a Web Developer Economics series a few years ago, where we looked at the various costs of being a web developer: Web Developer Economics: One-Off Software Costs Web Developer Economics: Hardware Costs Web Developer Economics: Monthly Service Costs Web Developer Economics: The Wrapup I’m sure some of that software and hardware has changed since then, but the spirit is the same. It costs money to have the things you need to do this job. I just wrote a similar article, but from the perspective of a business paying for the software it needs. That link is to Medium, but it was posted on the CodePen blog originally. Just giving that a shot to see what all the hubbub about Medium is about. Direct Link to Article — Permalink The post The Software We Pay For appeared first on CSS-Tricks....

Read More

It’s not about the device.

Ever have that, “Ugighgk, another device to support?!” feeling? Like, perhaps when you heard that wrist devices have browsers? Ethan’s latest post is about that. Personally, the Apple Watch is interesting to me not because it’s a watch. Rather, it’s interesting to me because it’s a smaller-than-normal touchscreen attached to a cellular antenna, and one that’s not necessarily on the most reliable connection. It helps me look past the device, and to think about how someone will interact with my work under those conditions. Once I do that, I can start to design accordingly. The post is nice reminder to revisit the idea of responsive design in our heads. The seismic shifts in how we consume the web is why web design and development shifted this way. So, enough thinking about specific devices. Instead, let’s make our approaches responsive and flexible, then new devices will come along. They will inevitably slot themselves right in without us having to re-design or re-code anything. Direct Link to Article — Permalink The post It’s not about the device. appeared first on CSS-Tricks....

Read More

Blue Beanie Day 2018

Another year! You better not cry, you better not shout, I’m telling you why: @BlueBeanieDay is coming Nov. 30! Start sharing your #bbd photos, links, articles, and videos now: https://t.co/3US4vHBsDR#a11y #WebStandards #InclusiveDesign #ProgressiveEnhancement pic.twitter.com/AiV3ktRqka — zeldman (@zeldman) October 24, 2018 I feel the same this year as I have in the past. Web standards, as an overall idea, has entirely taken hold and won the day. That’s worth celebrating, as the web would be kind of a joke without them. So now, our job is to uphold them. We need to cry foul when we see a browser go rogue and ship an API outside the standards process. That version of competition is what could lead the web back to a dark place where we’re creating browser-specific versions. That becomes painful, we stop doing it, and slowly, the web loses. Direct Link to Article — Permalink The post Blue Beanie Day 2018 appeared first on CSS-Tricks....

Read More

What If?

Harry Roberts writes about working on a project with a rather nasty design flaw. The website was entirely dependent on images loading before rendering any of the content. He digs into why this bad for accessibility and performance but goes further to describe how this can ripple into other problems: While ever you build under the assumption that things will always work smoothly, you’re leaving yourself completely ill-equipped to handle the scenario that they don’t. Remember the fallacies; think about resilience. Harry then suggests that we should always ask ourselves a key question when developing a website: what if this image doesn’t load? For example, if the user is on a low-end device, using a flakey network, using an obscure browser, looking at the site without a crucial API or feature available… you get the idea. While we’re on this note, we asked what makes a good front-end developer a little while back and I think this is the best answer to that question after reading Harry’s post: a good front-end developer is constantly asking themselves, “What if?” Direct Link to Article — Permalink The post What If? appeared first on CSS-Tricks....

Read More
www.000webhost.com