Tags: technology

470

sparkline

Wednesday, January 1st, 2020

Bound in Shallows: Space Exploration and Institutional Drift

If a human civilization beyond Earth ever comes into being, this will be unprecedented in any historical context we might care to invoke—unprecedented in recorded history, unprecedented in human history, unprecedented in terrestrial history, and so on. There have been many human civilizations, but all of these civilizations have arisen and developed on the surface of Earth, so that a civilization that arises or develops away from the surface of Earth would be unprecedented and in this sense absolutely novel even if the institutional structure of a spacefaring civilization were the same as the institutional structure of every civilization that has existed on Earth. For this civilizational novelty, some human novelty is a prerequisite, and this human novelty will be expressed in the mythology that motivates and sustains a spacefaring civilization.

A deep dive into deep time:

Record-keeping technologies introduce an asymmetry into history. First language, then written language, then printed books, and so and so forth. Should human history extend as far into the deep future as it now extends into the deep past, the documentary evidence of past beliefs will be a daunting archive, but in an archive so vast there would be a superfluity of resources to trace the development of human mythologies in a way that we cannot now trace them in our past. We are today creating that archive by inventing the technologies that allow us to preserve an ever-greater proportion of our activities in a way that can be transmitted to our posterity.

Monday, December 2nd, 2019

Just enough Internet | doteveryone

The carbon cost of collecting and storing data no one can use is already a moral issue.

So before you add another field, let alone make a new service, can you be sure it will make enough of a difference to legitimise its impact on the planet?

Wednesday, November 20th, 2019

2019 End-of-Year Thoughts Archives | CSS-Tricks

I’m really enjoying this end-of-the-year round-up from people speaking their brains. It’s not over yet, but there’s already a lot of thoughtful stuff to read through.

There are optimistic hopeful thoughts from Sam and from Ire:

Only a few years ago, I would need a whole team of developers to accomplish what can now be done with just a few amazing tools.

And I like this zinger from Geoff:

HTML, CSS, and JavaScript: it’s still the best cocktail in town.

Then there are more cautious prognostications from Dave and from Robin:

The true beauty of web design is that you can pick up HTML, CSS, and the basics of JavaScript within a dedicated week or two. But over the past year, I’ve come to the conclusion that building a truly great website doesn’t require much skill and it certainly doesn’t require years to figure out how to perform the coding equivalent of a backflip.

What you need to build a great website is restraint.

Saturday, November 16th, 2019

Morphosis: Goliath, David, Adam

A biblical short story from Adam Roberts.

Thursday, November 7th, 2019

Stab a Book, the Book Won’t Die — by Craig Mod

Craig compares and contrasts books to “attention monsters”:

That is, any app / service / publication whose business is predicated on keeping a consumer engaged and re-engaged for the benefit of the organization (often to the detriment of the mental and physical health of the user), dozens if not hundreds or thousands of times a day.

Wednesday, November 6th, 2019

The web is not dying | Go Make Things

A counterpart to the piece by Baldur that I linked to yesterday:

There are many challenges to face as the web grows.

Most of them are people problems. Habits. Inertia. A misalignment of priorities with user needs. Those can be overcome.

Tuesday, November 5th, 2019

The Web Falls Apart – Baldur Bjarnason

This isn’t a “the web is doomed, DOOMED, I tells ya” kind of blog post. It’s more in the “the web in its current form isn’t sustainable and will collapse into a simpler, more sustainable form, possibly several” genre.

Baldur points to the multiple causes of the web’s current quagmire.

I honestly have no idea on how to mitigate this harm or even how long the decline is going to take. My hope is that if we can make the less complex, more distributed aspects of the web safer and more robust, they will be more likely to thrive when the situation has forced the web as a whole to break up and simplify.

Tuesday, October 15th, 2019

Jeremy Keith & Remy Sharp - How We Built the World Wide Web in Five Days on Vimeo

Here’s the talk that Remy and I gave at Fronteers in Amsterdam, all about our hack week at CERN. We’re both really pleased with how this turned out and we’d love to give it again!

Monday, October 14th, 2019

The World-Wide Work. — Ethan Marcotte

Here’s the transcript of Ethan’s magnificent closing talk from New Adventures. I’m pretty sure this is the best conference talk I’ve ever had the honour of seeing.

Wednesday, September 18th, 2019

The Appification of Everything & Why it Needs to End

When your only tool seems like a smartphone, everything looks like an app.

Amber writes on Ev’s blog about products that deliberately choose to be dependent on smartphone connectivity:

We read service outage stories like these seemingly every week, and have become numb to the fundamental reality: The idea of placing the safety of yourself, your child, or another loved one in the hands of an app dependent on a server you cannot touch, control, or know the status of, is utterly unacceptable.

Thursday, August 8th, 2019

Priorities

I recently wrote about a web-specific example of a general principle for choosing the right tool for the job:

JavaScript should only do what only JavaScript can do.

I was—yet again—talking about appropriateness. Use the right technology for the task at hand. Here’s the example I gave:

It feels “wrong” when a powerful client-side JavaScript framework is applied to something that could be accomplished using HTML. Making a blog that’s a single page app is over-engineering.

Surprisingly, I got some pushback on this. Šime Vidas wrote:

Based on my experience, this is not necessarily the case.

Going from server-side rendering and progressive enhancement via JS to a single-page app powered by a JS framework was a enormous reduction in complexity for me (so the opposite of over-engineering).

(Emphasis mine.) He goes on to say:

My main concerns are ease of use & maintainability. If you get those things right, you’re good and it’s not over-engineering.

There’s no doubt that maintainability is a desirable goal. And ease of use for the developer is also important …but I think they pale in comparison to ease of use for the end user.

To be fair, the specific use-case I mentioned was making a blog. And a blog is a personal thing. You can do whatever the heck you like on your own website and don’t let anyone tell you otherwise.

So I probably chose a poor example to illustrate my point. I was thinking more about when you’re making websites for a living. You’re being paid money to make something available on the web. In that situation, I strongly believe that user needs should win out over developer convenience.

I wrote about this recently:

As a user-centred developer, my priority is doing what’s best for end users. That’s not to say I don’t value developer convenience. I do. But I prioritise user needs over developer needs. And in any case, those two needs don’t even come into conflict most of the time.

That’s why I responded to Šime, saying:

Your main concern should be user needs—not your own.

When I talk about over-engineering, I’m speaking from the perspective of end users, not developers.

Before considering your ease of use, and maintainability, consider users first.

In fairness to Šime, he’s being very open and honest about his priorities. I admire that. I’ve seen too many developers try to provide user experience justifications for decisions made for developer convenience. Once again I recommend Alex’s excellent article, The “Developer Experience” Bait-and-Switch:

The swap is executed by implying that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true.

Now I worry I wasn’t specific enough when I talked about choosing appropriate technology:

Appropriateness is something I keep coming back to when it comes to evaluating web technologies. I don’t think there are good tools and bad tools; just tools that are appropriate or inapropriate for the task at hand.

I should have made it clear that I was talking about what is appropriate or inapropriate for users. I think I made the mistake of assuming that this was obvious, and didn’t need saying. I’ll try not to make that mistake again.

There’s a whole group of tools where this point isn’t even relevant—build tools, task runners, version control …anything that never directly touches the end user; use whatever works for you. But if you’re making decisions around HTML, ARIA, CSS, or JavaScript, then appropriateness for the end user should take precedence.

If you’re in that situation—you are being paid money to make websites, and you are making technology decisions—I urge you to remember Charlie’s words: it isn’t about you.

Sunday, August 4th, 2019

What Technology Is Most Likely to Become Obsolete During Your Lifetime?

Old technology seldom just goes away. Whiteboards and LED screens join chalk blackboards, but don’t eliminate them. Landline phones get scarce, but not phones. Film cameras become rarities, but not cameras. Typewriters disappear, but not typing. And the technologies that seem to be the most outclassed may come back as a the cult objects of aficionados—the vinyl record, for example. All this is to say that no one can tell us what will be obsolete in fifty years, but probably a lot less will be obsolete than we think.

Wednesday, July 31st, 2019

The Real Dark Web

Charlie’s thoughts on dev perception:

People speak about “the old guard” and “stupid backwards techniques”, forgetting that it’s real humans, with real constraints who are working on these solutions. Most of us are working in a “stupid backwards way” because that “backwardsness” WORKS. It is something that is proven and is clearly documented. We can implement it confident that it will not disappear from fashion within a couple of years.

Tuesday, July 30th, 2019

Thursday, July 25th, 2019

Design tools are holding us back

My main concern about this new generation of tools is that they require a specific toolchain in order to function. “If you just use this version of React and just use this styling library and configure things in exactly this way, your designers can play around with coded components.” It worries me that teams would end up choosing (and subsequently holding onto) specific tools not because they’re the best choices for our users but because the designers’ and developers’ workflow depends on a specific toolchain to work properly.

Principle

I like good design principles. I collect design principles—of varying quality—at principles.adactio.com. Ben Brignell also has a (much larger) collection at principles.design.

You can spot the less useful design principles after a while. They tend to be wishy-washy; more like empty aspirational exhortations than genuinely useful guidelines for alignment. I’ve written about what makes for good design principles before. Matthew Ström also asked—and answered—What makes a good design principle?

  • Good design principles are memorable.
  • Good design principles help you say no.
  • Good design principles aren’t truisms.
  • Good design principles are applicable.

I like those. They’re like design principles for design principles.

One set of design principles that I’ve included in my collection is from gov.uk: government design principles . I think they’re very well thought-through (although I’m always suspicious when I see a nice even number like 10 for the amount of items in the list). There’s a great line in design principle number two—Do less:

Government should only do what only government can do.

This wasn’t a theoretical issue. The multiple departmental websites that preceded gov.uk were notorious for having too much irrelevant content—content that was readily available elsewhere. It was downright wasteful to duplicate that content on a government site. It wasn’t appropriate.

Appropriateness is something I keep coming back to when it comes to evaluating web technologies. I don’t think there are good tools and bad tools; just tools that are appropriate or inapropriate for the task at hand. Whether it’s task runners or JavaScript frameworks, appropriateness feels like it should be the deciding factor.

I think that the design principle from GDS could be abstracted into a general technology principle:

Any particular technology should only do what only that particular technology can do.

Take JavaScript, for example. It feels “wrong” when a powerful client-side JavaScript framework is applied to something that could be accomplished using HTML. Making a blog that’s a single page app is over-engineering. It violates this principle:

JavaScript should only do what only JavaScript can do.

Need to manage state or immediately update the interface in response to user action? Only JavaScript can do that. But if you need to present the user with some static content, JavaScript can do that …but it’s not the only technology that can do that. HTML would be more appropriate.

I realise that this is basically a reformulation of one of my favourite design principles, the rule of least power:

Choose the least powerful language suitable for a given purpose.

Or, as Derek put it:

In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.

ARIA should only do what only ARIA can do.

JavaScript should only do what only JavaScript can do.

CSS should only do what only CSS can do.

HTML should only do what only HTML can do.

Monday, July 15th, 2019

NeXT Software and Peripherals catalog Fall 1989

Brian found this scanned copy of a NeXT manual on the Internet Archive. I feel a great fondness for this machine after our CERN project.

Saturday, July 6th, 2019

Chaos Design: Before the robots take our jobs, can we please get them to help us do some good work?

This is a great piece! It starts with a look back at some of the great minds of the nineteenth century: Herschel, Darwin, Babbage and Lovelace. Then it brings us, via JCR Licklider, to the present state of the web before looking ahead to what the future might bring.

So what will the life of an interface designer be like in the year 2120? or 2121 even? A nice round 300 years after Babbage first had the idea of calculations being executed by steam.

I think there are some missteps along the way (I certainly don’t think that inline styles—AKA CSS in JS—are necessarily a move forwards) but I love the idea of applying chaos engineering to web design:

Think of every characteristic of an interface you depend on to not ‘fail’ for your design to ‘work.’ Now imagine if these services were randomly ‘failing’ constantly during your design process. How might we design differently? How would our workflows and priorities change?

Wednesday, July 3rd, 2019

inessential: No Algorithms

My hypothesis: these algorithms — driven by the all-consuming need for engagement in order to sell ads — are part of what’s destroying western liberal democracy, and my app will not contribute to that.

Wednesday, June 26th, 2019

Phenological Mismatch - e-flux Architecture - e-flux

Over the last fifty years, we have come to recognize that the fuel of our civilizational expansion has become the main driver of our extinction, and that of many of the species we share the planet with. We are now coming to realize that is as true of our cognitive infrastructure. Something is out of sync, felt everywhere: something amiss in the temporal order, and it is as related to political and technological shifts, shifts in our own cognition and attention, as it is to climatic ones. To think clearly in such times requires an intersectional understanding of time itself, a way of thinking that escapes the cognitive traps, ancient and modern, into which we too easily fall. Because our technologies, the infrastructures we have built to escape our past, have turned instead to cancelling our future.

James writes beautifully about rates of change.

The greatest trick our utility-directed technologies have performed is to constantly pull us out of time: to distract us from the here and now, to treat time as a kind of fossil fuel which can be endlessly extracted in the service of a utopian future which never quite arrives. If information is the new oil, we are already, in the hyper-accelerated way of present things, well into the fracking age, with tremors shuddering through the landscape and the tap water on fire. But this is not enough; it will never be enough. We must be displaced utterly in time, caught up in endless imaginings of the future while endlessly neglecting the lessons and potential actions of the present moment.