Tags: material

30

sparkline

Sunday, June 16th, 2019

BBC - Future - How to build something that lasts 10,000 years

As part of the BBC’s ongoing series on deep time, Alexander Rose describes the research he’s been doing for the clock of the long now—materials, locations, ideas …all the pieces that have historically combined to allow artifacts to survive.

Wednesday, April 24th, 2019

Who Are Design Systems For? | CSS-Tricks

Chris ponders the motivations behind companies sharing their design systems publicly. Personally, I’ve always seen it as a nice way of sharing work and saying “here’s what worked for us” without necessarily saying that anyone else should use the same system.

That said, I think Chris makes a good poin here:

My parting advice is actually to the makers of public design systems: clearly identify who this design system is for and what they are able to do with it.

Wednesday, April 10th, 2019

Split

When I talk about evaluating technology for front-end development, I like to draw a distinction between two categories of technology.

On the one hand, you’ve got the raw materials of the web: HTML, CSS, and JavaScript. This is what users will ultimately interact with.

On the other hand, you’ve got all the tools and technologies that help you produce the HTML, CSS, and JavaScript: pre-processors, post-processors, transpilers, bundlers, and other build tools.

Personally, I’m much more interested and excited by the materials than I am by the tools. But I think it’s right and proper that other developers are excited by the tools. A good balance of both is probably the healthiest mix.

I’m never sure what to call these two categories. Maybe the materials are the “external” technologies, because they’re what users will interact with. Whereas all the other technologies—that mosty live on a developer’s machine—are the “internal” technologies.

Another nice phrase is something I heard during Chris’s talk at An Event Apart in Seattle, when he quoted Brad, who talked about the front of the front end and the back of the front end.

I’m definitely more of a front-of-the-front-end kind of developer. I have opinions on the quality of the materials that get served up to users; the output should be accessible and performant. But I don’t particularly care about the tools that produced those materials on the back of the front end. Use whatever works for you (or whatever works for your team).

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. Like I said, from a user’s point of view, it’s irrelevant what text editor or version control system you use.

Now, you could make the argument that anything that is good for developer convenience is automatically good for user experience because faster, more efficient development should result in better output. While that’s true in theory, I highly recommend Alex’s post, The “Developer Experience” Bait-and-Switch.

Where it gets interesting is when a technology that’s designed for developer convenience is made out of the very materials being delivered to users. For example, a CSS framework like Bootstrap is made of CSS. That’s different to a tool like Sass which outputs CSS. Whether or not a developer chooses to use Sass is irrelevant to the user—the final output will be CSS either way. But if a developer chooses to use a CSS framework, that decision has a direct impact on the user experience. The user must download the framework in order for the developer to get the benefit.

So whereas Sass sits at the back of the front end—where I don’t care what you use—Bootstrap sits at the front of the front end. For tools like that, I don’t think saying “use whatever works for you” is good enough. It’s got to be weighed against the cost to the user.

Historically, it’s been a similar story with JavaScript libraries. They’re written in JavaScript, and so they’re going to be executed in the browser. If a developer wanted to use jQuery to make their life easier, the user paid the price in downloading the jQuery library.

But I’ve noticed a welcome change with some of the bigger JavaScript frameworks. Whereas the initial messaging around frameworks like React touted the benefits of state management and the virtual DOM, I feel like that’s not as prevalent now. You’re much more likely to hear people—quite rightly—talk about the benefits of modularity and componentisation. If you combine that with the rise of Node—which means that JavaScript is no longer confined to the browser—then these frameworks can move from the front of the front end to the back of the front end.

We’ve certainly seen that at Clearleft. We’ve worked on multiple React projects, but in every case, the output was server-rendered. Developers get the benefit of working with a tool that helps them. Users don’t pay the price.

For me, this question of whether a framework will be used on the client side or the server side is crucial.

Let me tell you about a Clearleft project that sticks in my mind. We were working with a big international client on a product that was going to be rolled out to students and teachers in developing countries. This was right up my alley! We did plenty of research into network conditions and typical device usage. That then informed a tight performance budget. Every design decision—from web fonts to images—was informed by that performance budget. We were producing lean, mean markup, CSS, and JavaScript. But we weren’t the ones implementing the final site. That was being done by the client’s offshore software team, and they insisted on using React. “That’s okay”, I thought. “React can be used server-side so we can still output just what’s needed, right?” Alas, no. These developers did everything client side. When the final site launched, the log-in screen alone required megabytes of JavaScript just to render a form. It was, in my opinion, entirely unfit for purpose. It still pains me when I think about it.

That was a few years ago. I think that these days it has become a lot easier to make the decision to use a framework on the back of the front end. Like I said, that’s certainly been the case on recent Clearleft projects that involved React or Vue.

It surprises me, then, when I see the question of server rendering or client rendering treated almost like an implementation detail. It might be an implementation detail from a developer’s perspective, but it’s a key decision for the user experience. The performance cost of putting your entire tech stack into the browser can be enormous.

Alex Sanders from the development team at The Guardian published a post recently called Revisiting the rendering tier . In it, he describes how they’re moving to React. Now, if this were a move to client-rendered React, that would make a big impact on the user experience. The thing is, I couldn’t tell from the article whether React was going to be used in the browser or on the server. The article talks about “rendering”—which is something that browsers do—and “the DOM”—which is something that only exists in browsers.

So I asked. It turns out that this plan is very much about generating HTML and CSS on the server before sending it to the browser. Excellent!

With that question answered, I’m cool with whatever they choose to use. In this case, they’re choosing to use CSS-in-JS (although, to be pedantic, there’s no C anymore so technically it’s SS-in-JS). As long as the “JS” part is JavaScript on a server, then it makes no difference to the end user, and therefore no difference to me. Not my circus, not my monkeys. For users, the end result is the same whether styling is applied via a selector in an external stylesheet or, for example, via an inline style declaration (and in some situations, a server-rendered CSS-in-JS solution might be better for performance). And so, as a user-centred developer, this is something that I don’t need to care about.

Except…

I have misgivings. But just to be clear, these misgivings have nothing to do with users. My misgivings are entirely to do with another group of people: the people who make websites.

There’s a second-order effect. By making React—or even JavaScript in general—a requirement for styling something on a web page, the barrier to entry is raised.

At least, I think that the barrier to entry is raised. I completely acknowledge that this is a subjective judgement. In fact, the reason why a team might decide to make JavaScript a requirement for participation might well be because they believe it makes it easier for people to participate. Let me explain…

It wasn’t that long ago that devs coming from a Computer Science background were deriding CSS for its simplicity, complaining that “it’s broken” and turning their noses up at it. That rhetoric, thankfully, is waning. Nowadays they’re far more likely to acknowledge that CSS might be simple, but it isn’t easy. Concepts like the cascade and specificity are real head-scratchers, and any prior knowledge from imperative programming languages won’t help you in this declarative world—all your hard-won experience and know-how isn’t fungible. Instead, it seems as though all this cascading and specificity is butchering the modularity of your nicely isolated components.

It’s no surprise that programmers with this kind of background would treat CSS as damage and find ways to route around it. The many flavours of CSS-in-JS are testament to this. From a programmer’s point of view, this solution has made things easier. Best of all, as long as it’s being done on the server, there’s no penalty for end users. But now the price is paid in the diversity of your team. In order to participate, a Computer Science programming mindset is now pretty much a requirement. For someone coming from a more declarative background—with really good HTML and CSS skills—everything suddenly seems needlessly complex. And as Tantek observed:

Complexity reinforces privilege.

The result is a form of gatekeeping. I don’t think it’s intentional. I don’t think it’s malicious. It’s being done with the best of intentions, in pursuit of efficiency and productivity. But these code decisions are reflected in hiring practices that exclude people with different but equally valuable skills and perspectives.

Rachel describes HTML, CSS and our vanishing industry entry points:

If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged.

I think there’s a comparison here with toxic masculinity. Toxic masculinity is obviously terrible for women, but it’s also really shitty for men in the way it stigmatises any male behaviour that doesn’t fit its worldview. Likewise, if the only people your team is interested in hiring are traditional programmers, then those programmers are going to resent having to spend their time dealing with semantic markup, accessibility, styling, and other disciplines that they never trained in. Heydon correctly identifies this as reluctant gatekeeping:

By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well.

This hurts everyone. It’s bad for your team. It’s even worse for the wider development community.

Last year, I was asked “Is there a fear or professional challenge that keeps you up at night?” I responded:

My greatest fear for the web is that it becomes the domain of an elite priesthood of developers. I firmly believe that, as Tim Berners-Lee put it, “this is for everyone.” And I don’t just mean it’s for everyone to use—I believe it’s for everyone to make as well. That’s why I get very worried by anything that raises the barrier to entry to web design and web development.

I’ve described a number of dichotomies here:

  • Materials vs. tools,
  • Front of the front end vs. back of the front end,
  • User experience vs. developer experience,
  • Client-side rendering vs. server-side rendering,
  • Declarative languages vs. imperative languages.

But the split that worries the most is this:

  • The people who make the web vs. the people who are excluded from making the web.

Saturday, February 16th, 2019

Tuesday, December 18th, 2018

Material Conference 2018: Craft on the Web - Charlotte Dann - YouTube

Charlotte’s opening talk at the Material conference was really excellent—a great narrative at the intersection of code and creativity.

Monday, November 26th, 2018

Warp and Weft — Paul Robert Lloyd

Paul was at the Material conference in Iceland too, and we had some good chats. Here, he speaks his brains with Deep Thoughts prompted by the event.

I really get where he’s coming from when he says that “certain websites feel more ‘webby’ than others”, but it sure is tricky to nail down.

Saturday, November 24th, 2018

Conferencing

I just wrapped up my last speaking gig of the year. It came at the end of a streak of attending European conferences without speaking at any of them—quite a nice feeling!

I already mentioned that I was in Berlin for the (excellent) Indie Web Camp. That was immediately followed by a one-day Accessibility Club conference. It was really, really good.

I have to say, I was initially apprehensive when I saw the sheer amount of speakers on the schedule. I was worried that my attention couldn’t handle it all. But the talks were a mixture of shorter 20 minute presentations, and a few longer 40 minute presentations. That worked really well—the day fairly zipped by. And just in case you think it would hard to have an entire day devoted to accessibility, the breadth of talks was remarkably diverse. Hats off to a well-organised and well-executed event!

The next day was Beyond Tellerrand. This has my favourite conference format: two days; one track; curated; a mix of design and development (see also An Event Apart and Smashing Conference). Marc’s love and care shines through every pore of the event. I thoroughly enjoyed the talks, and the hanging out with lovely people.

Alas, I had to miss the final afternoon of Beyond Tellerrand to head home to Brighton. I needed to get back for FF Conf. It was excellent, as always. Remy and Julie really give it their all. Remy even stepped in to give a (great) talk himself this year, when a speaker couldn’t make it.

A week later, I went to Iceland for Material. I really enjoyed last year’s inaugural event, and if anything, this year’s topped it. I just love how eclectic and different the talks are, and yet it all weirdly hangs together in a thoughtfully curated way. (Oh, and Remy, when you start to put together the line-up for next year’s FF Conf, be sure to check out Charlotte Dann—her talk at Material was the perfect mix of code and creativity.)

As well as sharing an organiser with Accessibility Club, Material had a similar format—keynote talks from invited presenters, interspersed with shorter talks by locals. The mix was great. I won’t even try to describe the range of topics. I’m not sure I could explain how a conference podium morphed into a bar at the end of one of the talks. I think the best description of Material would be to say it’s like the inside of Brian’s head. In a good way.

I was supposed to be back in Brighton for one night after Material, but the stormy weather kept myself and Jessica in Reykjavik for an extra night. Thanks to Brian’s hospitality, we had a bed for the night.

There followed a long travel day as we made our way from Reykjavik to Gatwick, and then straight on to Thessaloniki, where we spent five days even though we only had the clothes we packed for the brief trip to Iceland. (Yes, we went shopping.)

I was there to speak at Voxxed Days. These events happen in various locations around the world, and just a few weeks ago, I spoke at the one in Bristol. It was …different.

After experiencing so many lovingly crafted events—Accessibility Club, Beyond Tellerrand, FF Conf, and Material—I’m afraid that Voxxed Days Thessaloniki was quite a comedown. It’s not that it was corporate per se—I believe it’s organised by developers for developers—but it felt like it was for people who worked in corporate environments. There were multiple tracks (I’m really not a fan of that), and some great speakers on the line-up like Stephanie and Simona, but the atmosphere felt kind of grim in a David Brentian sort of way. It probably wasn’t helped by the cheeky chappie of an MC who referred to one of the speakers as “darling.”

Anyway, I spoke first thing on the first day and I didn’t end up sticking around long. Normally I don’t speak and run, but I didn’t fancy the vibe of the exhibitor hall with its booth-babesque sales teams. Voxxed Days doesn’t pay its speakers so I didn’t feel any great obligation to hang around. The magnificent food and rembetika music of Thessaloniki was calling.

I just got back from Greece, and that wraps up my conference attending (and speaking) for 2018. I’ve already got a couple of events lined up for 2019. I’m delighted to be speaking at the return of Colly’s New Adventures conference. I’m less delighted about preparing a brand new talk I promised—I’m really feeling the pressure to deliver the goods at such an auspicious event with an intimidatingly superb line-up of speakers.

I’m also going to be preparing a different all-new talk for An Event Apart Seattle in March. For once, I’m going to try to make it somewhat practical and talk about service workers. If you know of any other events that might want a presentation like that in 2019, drop me a line.

Perhaps I will see you in Nottingham or in Seattle. If you’re planning on going to New Adventures, use the discount code ADACTIO10 to get 10% of the price of the conference or workshop ticket. If you’re planning on going to An Event Apart, use the discount code AEAKEITH for $100 off.

Thursday, November 22nd, 2018

Essays « Object Lessons

Fax machines, pop-up books, radioactive televisions, writing boxes, microfilm readers, nuclear bomb cores, cupholders, bidets, jet engines, index cards, wiffle balls, oil barrels, lightning rods, playing cards, air conditioning, hair dryers, wheelchair ramps, handbags, diving bells, slippers, laundry chutes, sewing machines, pockets, skee-ball, safety pins, chalkboards, tote bags, holograms, hearing aids, dollhouses, billboards, airports, flash drives, cardigans, beer cans, stethoscopes, text editors, mugs, wallpaper, towel dispensers, bumber stickers, staplers, microscopes, fingerless gloves, wire hangers, toast, and more.

I’ll be in my bunk.

Tuesday, July 31st, 2018

Neodymium – Popula

Magnets: How Do They Work?

Magnetism might be the most romantic of all the topics in science to be metaphorically butchered by poets.

How Do We Keep Up? What Happens if CSS Grid Changes? - YouTube

Another great video from Jen as part of her Layout Land series. This time she addresses the question of the overwhelming technology landscape for developers and where they should invest their time.

She references my most recent talk, where I’ve been drawing a distinction between “materials” (HTML, CSS, JavaScript) and “tools” (everything else).

Thursday, July 12th, 2018

Steve Jobs on Prototypes - Snook.ca

I’ve thought often of how our design and prototyping tools for the web are often not of the web. Tools like Photoshop and Sketch and Invision create approximations but need to walk the line between being a tool to build native apps and to build web apps. They do well in their ability to quickly validate designs but do little to validate technical approach.

Sunday, July 8th, 2018

Brutalist Web Design

A website is not a magazine, though it might have magazine-like articles. A website is not an application, although you might use it to purchase products or interact with other people. A website is not a database, although it might be driven by one.

Friday, April 6th, 2018

Understandable excitement

An Event Apart Seattle just wrapped. It was a three-day special edition and it was really rather good. Lots of the speakers (myself included) were unveiling brand new talks, so there was a real frisson of excitement.

It was interesting to see repeating, overlapping themes. From a purely technical perspective, three technologies that were front and centre were:

  • CSS grid,
  • variable fonts, and
  • service workers.

From listening to other attendees, the overwhelming message received was “These technologies are here—they’ve arrived.” Now, depending on your mindset, that understanding can be expressed as “Oh shit! These technologies are here!” or “Yay! Finally! These technologies are here!”

My reaction is very firmly the latter. That in itself is an interesting data-point, because (as discussed in my talk) my reaction towards new technological advances isn’t always one of excitement—quite often it’s one of apprehension, even fear.

I’ve been trying to self-analyse to figure out which kinds of technologies trigger which kind of reaction. I don’t have any firm answers yet, but it’s interesting to note that the three technologies mentioned above (CSS grid, variable fonts, and service workers) are all additions to the core languages of the web—the materials we use to build the web. Frameworks, libraries, build tools, and other such technologies are more like tools than materials. I tend to get less excited about advances in those areas. Sometimes advances in those areas not only fail to trigger excitement, they make me feel overwhelmed and worried about falling behind.

Since figuring out this split between materials and tools, it has helped me come to terms with my gut emotional reaction to the latest technological advances on the web. I think it’s okay that I don’t get excited about everything. And given the choice, I think maybe it’s healthier to be more excited about advances in the materials—HTML, CSS, and JavaScript APIs—than advances in tooling …although, it is, of course, perfectly possible to get equally excited about both (that’s just not something I seem to be able to do).

Another split I’ve noticed is between technologies that directly benefit users, and technologies that directly benefit developers. I think there was a bit of a meta-thread running through the talks at An Event Apart about CSS grid, variable fonts, and service workers: all of those advances allow us developers to accomplish more with less. They’re good for performance, in other words. I get much more nervous about CSS frameworks and JavaScript libraries that allow us to accomplish more, but require the user to download the framework or library first. It feels different when something is baked into browsers—support for CSS features, or JavaScript APIs. Then it feels like much more of a win-win situation for users and developers. If anything, the onus is on developers to take the time and do the work and get to grips with these browser-native technologies. I’m okay with that.

Anyway, all of this helps me understand my feelings at the end of An Event Apart Seattle. I’m fired up and eager to make something with CSS grid, variable fonts, and—of course—service workers.

Thursday, April 5th, 2018

#davewentandroid - daverupert.com

Yeah. Fuck this. That’s creepy. Technically I opted into this feature because Google Maps asked “Google Maps would like to know your location, YES or NO?” Of course my answer was “YES” because, hey, it’s a fucking map. I didn’t realize I consented to having my information and location history stored indefinitely on Google’s servers.

I began all the work of disabling this “feature” but it seemed like a fruitless task. Also worth noting, Google Maps for iOS keeps Location History as well.

Friday, March 30th, 2018

Putting Civilization in a Box Means Choosing Our Legacy

A run-down of digital preservation technologies for very, very long-term storage …in space.

Sunday, March 4th, 2018

Futurists & realists – The Man in Blue

Cameron contrasts Syd Mead with Frank Lloyd Wright.

Mastery of materials is a valuable thing to have. It will help you build what’s needed now and forge ahead into the near future. But vision is also valuable – it helps inspire and drive teams, and lays out a longer term future that can alter the path of humanity. What I take from the futurists and the realists is that there’s a place for every person and every process; what you need to do is find your own place, get comfortable, and own it.

Monday, February 26th, 2018

Tips for Running Workshops - TimKadlec.com

I’ve just come back from running a workshop at Webstock in New Zealand, followed by another one in Hong Kong. I heartily concur with Tim’s advice here. I’ve certainly migrated to having a more modular approach to workshops. In fact, these days I have little to no slides. Instead, it’s all about being flexible.

You can spend forever carefully crafting and refining your workshop and coming up with solid exercises but at the end of the day, you need to be ready to go with the flow.

Some sections you wanted to cover you may not get to. Some topics you hadn’t allotted a lot of time to may need to become more detailed. That’s all fine because the workshop is about helping them, not yourself.

Friday, January 12th, 2018

Saving Your Web Workflows with Prototyping · Matthias Ott – User Experience Designer

A well-written (and beautifully designed) article on the nature of the web, and what that means for those of us who build upon it. Matthias builds on the idea of material honestly and concludes that designing through prototypes—rather than making pictures of websites—results in a truer product.

A prototyping mindset means cultivating transparency and showing your work early to your team, to users – and to clients as well, which can spark excited conversations. A prototyping mindset also means valuing learning over fast results. And it means involving everyone from the beginning and closely working together as a team to dissolve the separation of linear workflows.

Thursday, December 7th, 2017

The User Experience of Design Systems

When you start a redesign process for a company, it’s very easy to briefly look at all their products (apps, websites, newsletters, etc) and first of all make fun of how bad it all looks, and then design this one single design system for everything. However, once you start diving into why those decisions were made, they often reveal local knowledge that your design system doesn’t solve.

In this talk transcript, Rune Madsen enumerates the reasons for his informed scepticism towards design systems:

  1. The first concern, which is also the main argument of this talk, is that humans – especially designers and engineers – are obsessed with creating systems of order. This is not really driven by a demand from users, so they often tend to benefit the designer, not the user.
  2. My second concern relates to what I believe design systems is doing to our digital experience. We’ve always had trends in graphic design (Swiss design, Flat UI, etc), but I’m getting increasingly concerned that this broad adoption of design systems is creating a design monoculture that really narrows the idea of what digital products can be.
  3. My third concern is that with all this talk about design systems, there’s very little talk about the real problem in digital design, which is processes and tools. Designers love making design manuals, but any design system will completely and utterly fail if it doesn’t help people in the organization produce faster and better products.

Monday, September 4th, 2017

Material Conference 2017: Psychology and the Web - Amber Wilson - YouTube

Here’s Amber’s great talk from the great Material conference last month in Iceland.

Amber Wilson worked in the field of Psychology for many years and is now a budding Web developer at a design agency in Brighton. New to Web development, she is continually eager to improve her skills.

(The silhouettes of Jessica, me, and Joschi in the front row make it look like Mystery Science Theater 3000.)