Link tags: sim

87

sparkline

Make Me Think | Jim Nielsen’s Weblog

The removal of all friction should’t be a goal. Making things easy and making things hard should be a design tool, employed to aid the end user towards their loftiest goals.

The Resiliency of the Internet | Jim Nielsen’s Weblog

An ode to the network architecture of the internet:

I believe the DNA of resiliency built into the network manifests itself in the building blocks of what’s transmitted over the network. The next time somebody calls HTML or CSS dumb, think about that line again:

That simplicity, almost an intentional brainlessness…is a key to its adaptability.

It’s not a bug. It’s a feature.

Yes! I wish more web developers would take cues from the very medium they’re building atop of.

this vs that - What is the difference between ___ and ___ in the front-end development?

A handy reference for explaining the differences between confusingly similar bits of HTML, CSS, and JavaScript.

Lateral Thinking With Withered Technology · Matthias Ott – User Experience Designer

What web development can learn from the Nintendo Game and Watch.

The Web now consists of an ever-growing number of different frameworks, methodologies, screen sizes, devices, browsers, and connection speeds. “Lateral thinking with withered technology” – progressively enhanced – might actually be an ideal philosophy for building accessible, performant, resilient, and original experiences for a wide audience of users on the Web.

Make me think! – Ralph Ammer

This is about seamful design.

We need to know things better if we want to be better.

It’s also about progressive enhancement.

Highly sophisticated systems work flawlessly, as long as things go as expected.

When a problem occurs which hasn’t been anticipated by the designers, those systems are prone to fail. The more complex the systems are, the higher are the chances that things go wrong. They are less resilient.

A Tale of Two Clocks

Doomsday vs. the Long Now.

Frank Chimero · Redesign: On This Design

Most experienced designers want concision—clear, robust, consistent, elegant systems that avoid redundancy. Concise designs are smoother to implement, faster to render, quicker to understand, and easier to hand-off and maintain. Achieving a simplicity with clarity means that you’re engaging with the fundamentals of the problem (and of your craft) at the correct fidelity. You’ve cut through complexity with insight, understanding, and committed decision-making. That third one is critical. A lot of complexity comes from an unwillingness to commit to the things that insight and understanding surface.

This Page is Designed to Last: A Manifesto for Preserving Content on the Web

Geocities, LiveJournal, what.cd, now Yahoo Groups. One day, Medium, Twitter, and even hosting services like GitHub Pages will be plundered then discarded when they can no longer grow or cannot find a working business model.

Considering the needs of someone who wants to make and maintain a website, without the ridiculous complexity of “modern” web tooling:

How do we make web content that can last and be maintained for at least 10 years? As someone studying human-computer interaction, I naturally think of the stakeholders we aren’t supporting. Right now putting up web content is optimized for either the professional web developer (who use the latest frameworks and workflows) or the non-tech savvy user (who use a platform).

Music and Web Design | Brad Frost

I feel my trajectory as a musician maps to the trajectory of the web industry. The web is still young. We’re all still figuring stuff out and we’re all eager to get better. In our eagerness to get better, we’re reaching for more complexity. More complex abstractions, build processes, and tools. Because who wants to be bored playing in 4/4 when you can be playing in 7/16?

I hope we in the web field will arrive at the same realization that I did as a musician: complexity is not synonymous with quality.

Can I get an “Amen!”?

Everything is Amazing, But Nothing is Ours – alexdanco.com

Worlds of scarcity are made out of things. Worlds of abundance are made out of dependencies. That’s the software playbook: find a system made of costly, redundant objects; and rearrange it into a fast, frictionless system made of logical dependencies. The delta in performance is irresistible, and dependencies are a compelling building block: they seem like just a piece of logic, with no cost and no friction. But they absolutely have a cost: the cost is complexity, outsourced agency, and brittleness. The cost of ownership is up front and visible; the cost of access is back-dated and hidden.

Keeping it simple with CSS that scales - Andy Bell

The transcript of Andy’s talk from this year’s State Of The Browser conference.

I don’t think using scale as an excuse for over-engineering stuff—especially CSS—is acceptable, even for huge teams that work on huge products.

Simplicity (II)

When you ever had to fix just a few lines of CSS and it took two hours to get an ancient version of Gulp up and running, you know what I’m talking about.

I feel seen.

When everything works, it feels like magic. When something breaks, it’s hell.

I concur with Bastian’s advice:

I have a simple rule of thumb when it comes to programming:

less code === less potential issues

And this observation rings very true:

This dependency hell is also the reason why old projects are almost like sealed capsules. You can hardly let a project lie around for more than a year, because afterwards it’s probably broken.

Don’t build that app! – Luke Jackson - YouTube

This is a fascinating look at how you can get the benefits of React and npm without using React and npm.

Here’s an accompanying article on the same topic.

Don't build that app! – Luke Jackson

Approachable Tooling | TimKadlec.com

It’s fantastic that our web plumbing has gotten more powerful—tooling today is capable of so much. But all too often, that power comes with increased complexity that negatively impacts developer efficiency. Sometimes that’s unavoidable. The simplest approach doesn’t always win. But that should be the goal—to make things as simple as possible while still accomplishing what needs to be done. Like excellent plumbing, these systems should be as mostly invisible—chugging along, doing what we need them to do without getting in our way.

What I Learned Co-Founding Dribbble – SimpleBits

Twenty hard-won lessons from Dan from ten years of Dribbble.

We sent 50 shirts along with a card to friends and colleagues announcing Dribbble’s beta back in 2008. This first batch of members played a pivotal role in the foundation of the community and how it would develop. The shirt helped guilt them into actually checking out the site.

I think I still have my T-shirt somewhere!

Designing for actual performance by Adam Silver

This is something I’ve been thinking about a lot lately. The justification for single page apps feels like circular thinking to me. A JavaScript framework is needed to avoid full page refreshes because full page refreshes are expensive because that means assets will be reloaded …assets like the JavaScript framework that only exists to avoid the full page refresh.

This is how it goes. We put a load of shit into a single web page. This makes the page slow. Slow to load, slow to render. Slow.

Instead of getting rid of the shit, we blame the page refresh.

Interview with Kyle Simpson (O’Reilly Fluent Conference 2016) - YouTube

I missed this when it was first posted three years ago, but now I think I’ll be revisiting this 12 minute interview every few months.

Everything that Kyle says here is spot on, nuanced, and thoughtful. He talks about abstraction, maintainability, learning, and complexity.

I want a transcript of the whole thing.

Interview with Kyle Simpson (O'Reilly Fluent Conference 2016)

Disenchantment - Tim Novis

I would urge front-end developers to take a step back, breathe, and reassess. Let’s stop over engineering for the sake of it. Let’s think what we can do with the basic tools, progressive enhancement and a simpler approach to building websites. There are absolutely valid usecases for SPAs, React, et al. and I’ll continue to use these tools reguarly and when it’s necessary, I’m just not sure that’s 100% of the time.

You probably don’t need that hip web framework - Charged

This is a bit ranty but it resonates with what I’ve been noticing lately:

I’ve discovered how many others have felt similarly, overwhelmed by the choices we have as modern developers, always feeling like there’s something we should be doing better.

CSS { In Real Life } | Building a dependency-free site in 2019

I think we’re often guilty of assuming that because our tools are great solutions for some things, they’re automatically the solution for everything.