Posts tagged “web”, page 7

Paul Robert Lloyd:

Such notions of craftsmanship can soon lead us down a dangerous path, raising questions around elitism and discrimination. These are accusations you could level towards the IndieWeb. For all its promise of giving people the tools to regain ownership of their online identity and content, to do so fully and effectively requires a proficiency for coding and familiarity with an endless barrage of acronyms. Encouraging participants to selfdogfood only exacerbates the near-impenetrability and narrowness of this movement.

Rob Weychert chimes in and gets a strong +1 from me:

I’ve been making websites for 20 years. I read a bunch about how to set up webmentions and gave up before I started. 🤷🏻‍♂️ https://t.co/iIv1BgQXlY

— Rob Weychert (@robweychert) November 27, 2018

If even web people find it difficult, how can we ever manage to empower non-web people to produce web-like content?

Ben Callahan:

When you strip away all the stuff we do to try to control the experience of a website, it turns out the web is pretty darn accessible. It only breaks when we break it.

Dave Rupert:

Let’s say we have a site with ~300 third-party scripts all responsibly loaded as async, what would be the User Experience costs and risks?

Ben Frain gives some very useful and pragmatic advice on how to build web front-end prototypes.

Producing something of high fidelity, perfectly matching any flat designs, runs counter to the notion of creating something quickly. The challenge for the prototyper is therefore how to cut corners that don’t impact the fidelity of the prototype.

Jeremy Keith adds:

In my experience, it’s vital that the prototype does not morph into the final product …no matter how tempting it sometimes seems.

Prototypes are made to be discarded (having validated or invalidated an idea). Making a prototype and making something for production require very different mindsets: with prototyping it’s all about speed of creation; with production work, it’s all about quality of execution.

Max Böck:

Text-only sites like these are usually treated as a MVP of sorts. A slimmed-down version of the real site, specifically for emergencies.

I’d argue though that in some aspects, they are actually better than the original.

This is the web as it was originally designed. Pure information, with zero overhead. Beautiful in a way.

Jeremy Keith:

I really like this design pattern. Cover 80% of the use cases with a declarative solution in HTML, but also provide an imperative alternative in JavaScript that gives more power. HTML5 has plenty of examples of this pattern. But I feel like the history of web standards has a few missed opportunities too.

In recent years there’s been a push to expose low-level browser features to developers. They’re inevitably exposed as JavaScript APIs. In most cases, that makes total sense. I can’t really imagine a declarative way of accessing the fetch or cache APIs, for example. But I think we should be careful that it doesn’t become the only way of exposing new browser features. I think that, wherever possible, the design pattern of exposing new features declaratively and imperatively offers the best of the both worlds—ease of use for the simple use cases, and power for the more complex use cases.

Rachel Andrew:

There is frequently talk about how developers whose main area of expertise is CSS feel that their skills are underrated. I do not think we help our cause by talking about CSS as this whacky, quirky language. CSS is unlike anything else, because it exists to serve an environment that is unlike anything else. However we can start to understand it as a designed language, with much consistency. It has codified rules and we can develop ways to explain and teach it, just as we can teach our teams to use Bootstrap, or the latest JavaScript framework.

Brad Frost:

JavaScript is eating the world and the rest of the frontend stack with it. Those server-side languages people used to write in? Node. HTML? JSX. Styling? We do that in JS now too. HTML, CSS, and JavaScript are three sturdy, capable languages that each have their own histories, nuances, and best practices. I do worry that as we author more and more in JS we risk losing those hard-won HTML/CSS best practices. Of course, it’s totally possible to preserve those HTML/CSS best practices even as we write everything in JS, which is why I want to make sure libraries like React are accessible to frontend people like me who don’t come from a JavaScript/programming background.

Kevin Ball:

“Real programmers” were antisocial, geeky, and only cared about computing. If you didn’t fit the profile you didn’t belong.

With the growth of the importance of front-end development, we’re seeing the story play out again.

The systematic devaluation of CSS, and more, the people who use CSS.

At the top of Jeremy’s list, other people’s Javascript:

At number one with a bullet, it’s all the crap that someone else tells us to put on our websites. Analytics. Ads. Trackers. Beacons. “It’s just one little script”, they say. And then that one little script calls in another, and another, and another.

It’s so disheartening when you’ve devoted your time and energy into your web font loading strategy, and optimising your images, and unbundling your JavaScript …only to have someone else’s JavaScript just shit all over your nice performance budget.

Steven Garrity:

The inability to deal with long strings of text is the most basic and maybe most common way components can fail when coming in contact with real data. You thought the tab would be labelled “Settings”? Well, now it’s called “Application Preferences.” Oh, and the product launches tomorrow.

Lily Hay Newman, for Wired:

Google's Chrome browser turns 10 today, and in its short life it has introduced a lot of radical changes to the web. From popularizing auto-updates to aggressively promoting HTTPS web encryption, the Chrome security team likes to grapple with big, conceptual problems. That reach and influence can be divisive, though, and as Chrome looks ahead to its next 10 years, the team is mulling its most controversial initiative yet: fundamentally rethinking URLs across the web.

Ethan Marcotte:

Lately, I’ve been reflecting on some of the language I use to talk about accessibility—or, more specifically, to talk about the people I’m designing for. Like, I’ve spoken in the past about “screen reader users” or “users who navigate primarily by keyboard.” (Heck, maybe you have too.) And I’ve been wondering if that language is problematic, since it implicitly treats those groups as monoliths: as though every single person using a given piece of assistive technology would browse, behave, and think exactly the same. In other words, if two different people visit your site with the same speaking browser, each of those people will have their own expectations of how a website should work, and how information will be arranged.

Cole Henley makes some very astute observations on the value and purpose of web development tools:

At the risk of sounding like a Luddite, I do worry that the adoption of tools for producing websites often lacks focus and a clear reason for “why.” As a largely self-taught profession, we have often lent on our peers for guidance and direction. But how often is the context of this guidance comparable to our own? As I said earlier, can the efforts to produce code for enterprise website applications across large, distributed teams share some equivalence with the work many of us produce in creating small, brochure sites for small to medium-sized businesses and not-for-profits? Does one shoe fit all? And are we in danger of focusing too much on the “Pencils rather than the drawing”? The Process over the Product?

I found this question particularly hard to grapple with:

But one of the ways CSS Zen Garden was used to persuade people about the merits of a web standards approach was to suggest that we can retain the markup and replace the CSS. However in reality how many projects has this ever happened on? What is the realistic lifespan of a thing we produce? And do we tend to underestimate how disposable our code truly is?

Sara Soueidan:

Using the color wheel to pick colors has many benefits. One of the main advantages of HSL is that creating color harmonies becomes a piece of cake.