Tags: diversity

55

sparkline

Monday, June 12th, 2023

The continuing tragedy of CSS: thoughts from CSS Day 2023 · Paul Robert Lloyd

With new or expanded modules for layout, typography, animation, audio (though sadly not speech) and more, it’s possible to specialise in a subset of CSS. Yet when aspects of frontend development not involving JavaScript are seen as ignorable by employers, few will get this opportunity.

Paul shares his big-picture thoughts after CSS Day:

But one CSS conference isn’t enough. This language is now so broad and deep, its implementation across browsers never more stable and complete, that opportunities to grow the community abound.

Wednesday, April 12th, 2023

Scholarship sponsorship

I wrote a while back about the UX London 2023 scholarship programme. Applications are still open (until May 19th) so if you know someone who you think should apply, here’s the link. As I said then:

Wondering if you should apply? It’s hard to define exactly who qualifies for a diversity scholarship, but basically, the more your life experience matches mine, the less qualified you are. If you are a fellow able-bodied middle-aged heterosexual white dude with a comfortable income, do me a favour and don’t apply. Everyone else, go for it.

The response so far has been truly amazing—so many great applicants!

And therein lies the problem. Clearleft can only afford to sponsor a limited number of people. It’s going to be very, very, very hard to have to whittle this down.

But perhaps you can help. Do you work at a company that could afford to sponsor some places? If so, please get in touch!

Just to be clear, this would be different from the usual transactional sponsorship opportunities for UX London where we offer you a package of benefits in exchange for sponsorship. In the case of diversity scholarships, all we can offer you is our undying thanks.

I’ll admit I have an ulterior motive in wanting to get as many of the applicants as possible to UX London. The applications are positively aglow with the passion and fervour of the people applying. Frankly, that’s exactly who I want to hang out with at an event.

Anyway, on the off chance that your employer might consider this investment in the future of UX, spread the word that we’d love to have other companies involved in the UX London diversity scholarship programme.

Tuesday, February 21st, 2023

UX London 2023 scholarship programme

If you’re a western white guy like me, you’re playing life on its easiest setting. If you’re also a designer, then you should get a ticket to UX London. You can probably get work to pay for it. Share this list of reasons to attend with your boss if you have to.

If, on the other hand, you don’t benefit from the same level of privilege as me, you might still be able to attend UX London 2023. We’re running a scholarship programme.

“We” in this case is Clearleft. But as we also need to at least break even on this event, there are only a limited number of scholarship spots available.

Now, if your company were in a position to pony up some moolah to sponsor more diversity scholarship places, we would dearly love to hear from you—get in touch!

If you think you might qualify for a diversity scholarship, fill in this form before May 19th. We’ll then notify you by May 26th, whether you application is successful or not. And if you’re worried about the additional costs of travel and accommodation, I’m sure we can figure something out.

Wondering if you should apply? It’s hard to define exactly who qualifies for a diversity scholarship, but basically, the more your life experience matches mine, the less qualified you are. If you are a fellow able-bodied middle-aged heterosexual white dude with a comfortable income, do me a favour and don’t apply. Everyone else, go for it.

Tuesday, September 13th, 2022

That was dConstruct 2022

dConstruct 2022 happened last Friday, September 9th.

And what an event it was! All eight talks were superb. To have eight speakers and not a single dud is pretty great. To have eight speakers and each one be absolutely brilliant is more than I could’ve hoped for.

Hidde has written a summary of the talks. I loved each and every one. I got to sit there in the front row of the beautiful Duke of York’s cinema and watch these supersmart people blow my mind.

With six of the eight speakers having spoken at previous dConstructs, there was a lot of nostalgia in the air on Friday.

It was the last dConstruct.

A lot of people seemed surprised by this even though I kept saying it was a one-off event. Really, the last dConstruct happened in 2015. This year’s event was a one-time-only anniversary event.

Obviously because the day was so great, people expressed sadness and disappointment that there wouldn’t be another. But like I said, if a band like The Velvet Underground reforms to do one last gig, that’s pretty cool; but if a band like The Velvet Underground reforms to go on endless tours, that’s kind of sad. It’s time to move on. Have one last blow-out and go out in style.

And who knows? Maybe there’ll be some other kind of dConstructy gathering in a different format. Perhaps an evening salon event is more suited to this kind of interdisciplinary mish-mash. But as a one-day conference, dConstruct is now officially over.

To be honest, there was never any doubt that dConstruct 2022 would be an excellent day of talks. I knew that each of the speakers would deliver the goods. I played it somewhat safe with the line-up. Because this was a kind of “best of” event, I could draw upon speakers from previous years who were guaranteed to be mesmerising.

In a weird way, that also highlights the biggest problem with this year’s dConstruct. Even though every individual talk was terrific, when you pull back and look at the line-up in aggregate, you can’t help but notice its lack of diversity.

That’s on me.

I could show you the list of people I tried to get. I could talk you through the spots that fell through. But all I’d be doing is giving you excuses. I could show that my intentions were good, but intentions don’t matter as much as actions. The proof of the pudding is in the eating, and what we ate last Friday was wonderful but also sadly representative of dConstruct’s homogenous history. For that reason alone, it’s time to draw a line under dConstruct.

It was a bittersweet send-off. On the one hand, I got to enjoy a day of brilliant talks. On the other hand, I’m pretty disappointed in myself that the line-up wasn’t more diverse. I can make all the claims I want about valuing diversity, but they’re hollow without meaningful results.

So that’s enough looking to the past. I’m bidding farewell to dConstruct and setting my sights on the future, a future that features more and different voices.

If you came along to dConstruct 2022, thank you! If you enjoyed attending dConstruct just half as much as I enjoyed hosting it …well, then I enjoyed it twice as much as you.

Monday, July 18th, 2022

My comments to Competition and Markets Authority on mobile browser competition - Alistair Shepherd

A thoughtful response to the current CMA consultation:

The inability to compete with native apps using Progressive Web Apps fully—particularly on iOS—also has a big impact on my work and the businesses I have worked with. Progressive Web Apps are extremely accessible for development, allowing for the creation of a simple app in a fraction of the time and complexity of a native app. This is fantastic for allowing smaller agencies and businesses to innovate on the web and on mobile devices and to reach consumers. However the poor support for PWA features by Safari and by not allowing them in the App Store, Apple forces app development to be difficult, time consuming and extremely expensive. I have spoken with many companies who would have liked an app to compete with their larger competitors but are unable to afford the huge costs in developing a native app.

Get your response in by Friday by emailing browsersandcloud@cma.gov.uk.

Wednesday, February 2nd, 2022

2.5.6

The Competition and Markets Authority (CMA) recently published an interim report on their mobile ecosystems market study. It’s well worth reading, especially the section on competition in the supply of mobile browsers:

On iOS devices, Apple bans the use of alternative browser engines – this means that Apple has a monopoly over the supply of browser engines on iOS. It also chooses not to implement – or substantially delays – a wide range of features in its browser engine. This restriction has 2 main effects:

  • limiting rival browsers’ ability to differentiate themselves from Safari on factors such as speed and functionality, meaning that Safari faces less competition from other browsers than it otherwise could do; and
  • limiting the functionality of web apps – which could be an alternative to native apps as a means for mobile device users to access online content – and thereby limits the constraint from web apps on native apps. We have not seen compelling evidence that suggests Apple’s ban on alternative browser engines is justified on security grounds.

That last sentence is a wonderful example of British understatement. Far from protecting end users from security exploits, Apple have exposed everyone on iOS to all of the security issues of Apple’s Safari browser (regardless of what brower the user thinks they are using).

The CMA are soliciting responses to their interim report:

To respond to this consultation, please email or post your submission to:

Email: mobileecosystems@cma.gov.uk

Post: 


Mobile Ecosystems Market Study
Competition and Markets Authority

25 Cabot Square

London

E14 4QZ

Please respond by no later than 5pm GMT on 7 February 2022.

I encourage you to send a response before this coming Monday. This is the email I’ve sent.

Hello,

This response is regarding competition in the supply of mobile browsers and contains no confidential information.

I read your interim report with great interest.

As a web developer and the co-founder of a digital design agency, I could cite many reasons why Apple’s moratorium on rival browser engines is bad for business. But the main reason I am writing to you is as a consumer and a user of Apple’s products.

I own two Apple computing devices: a laptop and a phone. On both devices, I can install apps from Apple’s App Store. But on my laptop I also have the option to download and install an application from elsewhere. I can’t do this on my phone. That would be fine if my needs were met by what’s available in the app store. But clause 2.5.6 of Apple’s app store policy restricts what is available to me as a consumer.

On my laptop I can download and install Mozilla’s Firefox or Google’s Chrome browsers. On my phone, I can install something called Firefox and something called Chrome. But under the hood, they are little more than skinned versions of Safari. I’m only aware of this because I’m au fait with the situation. Most of my fellow consumers have no idea that when they install the app called Firefox or the app called Chrome from the app store on their phone, they are being deceived.

It is this deception that bothers me most.

Kind regards,

Jeremy Keith

To be fair to Apple, this deception requires collusion from Mozilla, Google, Microsoft, and other browser makers. Nobody’s putting a gun to their heads and forcing them to ship skinned versions of Safari that bear only cosmetic resemblance to their actual products.

But of course it would be commercially unwise to forego the app store as a distrubution channel, even if the only features they can ship are superficial ones like bookmark syncing.

Still, imagine what would happen if Mozilla, Google, and Microsoft put their monies where their mouths are. Instead of just complaining about the unjust situation, what if they actually took the financial hit and pulled their faux-browsers from the iOS app store?

If this unjustice is as important as representatives from Google, Microsoft, and Mozilla claim it is, then righteous indignation isn’t enough. Principles without sacrifice are easy.

If nothing else, it would throw the real situation into light and clear up the misconception that there is any browser choice on iOS.

I know it’s not going to happen. I also know I’m being a hypocrite by continuing to use Apple products in spite of the blatant misuse of monopoly power on display. But still, I wanted to plant that seed. What if Microsoft, Google, and Mozilla were the ones who walk away from Omelas.

Wednesday, December 1st, 2021

Webrise

Prompted by my talk, The State Of The Web, Brian zooms out to get some perspective on how browser power is consolidated.

The web is made of clients and servers. There’s a huge amount of diversity in the server space but there’s very little diversity when it comes to clients because making a browser has become so complex and expensive.

But Brian hopes that this complexity and expense could be distributed amongst a large amount of smaller players.

10 companies agreeing to invest $10k apiece to advance and maintain some area of shared interest is every bit as useful as 1 agreeing to invest $100k generally. In fact, maybe it’s more representative.

We believe that there is a very long tail of increasingly smaller companies who could do something, if only they coordinated to fund it together. The further we stretch this out, the more sources we enable, the more its potential adds up.

Tuesday, November 2nd, 2021

HmntyCntrd | Critical UX Event

This looks like an excellent (and very reasonably-priced) online event happening on November 12th with three panels:

  1. beyond accessibility,
  2. failure of diversity, and
  3. design as resistance!

Monday, August 2nd, 2021

The Oxymoron of “Data-Driven Innovation” – Chelsea Troy

Businesses focus on efficiencies—doing the things that net them the most money for the least effort. By contrast, taxpayer-funded public programs are designed and expected to cover everyone—including, and especially, the most marginalized. That’s why they’re taxpayer-funded; so they don’t face existential risk be eschewing profit-driven decision-making. Does this work perfectly? No. But I think about it a lot when people shit on the bigness and slowness of government. That bigness & slowness is supposed to create space and resources to account for the communities, that a “lean,” fast approach deliberately ignores.

Wednesday, July 7th, 2021

Back to the Bad Old Days of the Web – Jorge Arango

We’ve enjoyed a relatively long period when we didn’t have to think about which browser to use. Alas, that period is ending: I must now keep Chrome running all the time, much like I needed that PC in the early 2000s.

Wednesday, March 10th, 2021

Diversity and inclusion on the Clearleft podcast

The latest episode of the Clearleft podcast is out. It’s the penultimate episode of season two already! This episode is all about diversity and inclusion.

This might be my favourite episode so far. That might be because I’m not in it very much at all. I’ve kept my editorialising to a minimum to focus on the important voices.

Margaret Lee tells a powerful personal story from her talk at Leading Design in New York two years ago, Insights from a Reluctant Leader.

From the same event, there’s Farai Madzima talking about Cultural bias in design(ers). If you’ve seen Farai speak, then you know how engaging he is. This segment also gave me the opportunity to splice in some music. That was a fun technical challenge.

I also talked to Rifa. As well as getting her story for the podcast, it was just really great to catch up with her again. It’s been far too long.

Finally, I’ve got an interview Elaine dela Cruz from Project 23, a consultancy that’s been engaged by Clearleft:

The mission is to make workplaces fairer, happier and more productive. Through bespoke workshops, coaching and consultancy services; we support organisations to make sustainable changes that are relevant for today’s societal and business needs.

It was a real pleasure to take these four fantastic voices and put them together into one narrative thread. I have to say, I’m really pleased with the end result. I hope you’ll give it a listen. It’s 23 minutes long.

And please share this episode if you think it deserves a wider hearing.

Just one more episode to go in this season! Make sure you’re subscribed so you don’t miss the final episode next week: Apple, Spotify, Google, or just plain ol’ RSS.

Tuesday, October 13th, 2020

Feds may target Google’s Chrome browser for breakup - POLITICO

The unfair collusion between Google AMP and Google Search might just bite ‘em on the ass.

Monday, September 7th, 2020

What is the Value of Browser Diversity? - daverupert.com

I’ve thought about these questions for over a year and narrowed my feelings of browser diversity down to two major value propositions:

  1. Browser diversity keeps the Web deliberately slow
  2. Browser diversity fosters consensus and cooperation over corporate rule

Tuesday, May 26th, 2020

as days pass by — Browsers are not rendering engines

You see, diversity of rendering engines isn’t actually in itself the point. What’s really important is diversity of influence: who has the ability to make decisions which shape the web in particular ways, and do they make those decisions for good reasons or not so good?

Stuart responds to a post from Brian that was riffing off a post of mine from a while back. I like this kind of social network.

Thursday, February 6th, 2020

Switching to Firefox | Brad Frost

Like Brad, I switched to Firefox for web browsing and Duck Duck Go for searching quite a while back. I highly recommend it.

Monday, January 27th, 2020

Diary of an Engine Diversity Absolutist – Dan’s Blog

Dan responds to an extremely worrying sentiment from Alex:

The sentiment about “engine diversity” points to a growing mindset among (primarily) Google employees that are involved with the Chromium project that puts an emphasis on getting new features into Chromium as a much higher priority than working with other implementations.

Needless to say, I agree with this:

Proponents of a “move fast and break things” approach to the web tend to defend their approach as defending the web from the dominance of native applications. I absolutely think that situation would be worse right now if it weren’t for the pressure for wide review that multiple implementations has put on the web.

The web’s key differentiator is that it is a part of the commons and that it is multi-stakeholder in nature.

Saturday, December 14th, 2019

Building The Web

An interview conducted by Vitaly Friedman ahead of the 2019 View Source conference in Amsterdam.

Do you think, as of today, the Web is in the best shape it will ever be?

Well, to paraphrase Charles Dickens, “It is the best of the times; it is the worst of times,” because, in a sense, things are absolutely great today. Let’s just take it from the point of view of browsers and browser support for standards.

What you can do in a browser today just straight out of the box is amazing compared to the past. There are some little differences between browsers but, honestly, not like it used to be. Back in the day, if you were a Web developer, you spent maybe 50% of your time battling specific browser bugs trying to make one browser work like another browser, all this stuff, trying to make up for lack of standards.

It’s funny. I was listening to panel discussions we did at a conference I think 11 years ago, the AtMedia Conference in London. One of the questions I was asking the panelists was like, “What’s your wish list for CSS or browsers, in general?” They were saying things like, “Oh, if we had multiple background images, everything would be perfect. All my problems would be solved.”

They were all saying things that we have. They were all saying things that we have today, and we’ve got more. We have so much today that you couldn’t even imagine in the past, things like service workers where you can literally control network level stuff, amazing CSS things with Grid now and Flexbox. Amazing, right? One the one hand, yes, things are better than they’ve ever been.

Then, on another hand, not so much because, first of all, in the area of browsers, the fact that making a browser is now so complicated that only very, very, very, very few companies and organizations could do it and we’re kind of down to just two or three browser rendering engines, that’s not very healthy for something like the Web, which has always thrived on diversity. That’s something we’ll see how that plays out, so I’m uncomfortable about that but it remains to be seen.

Then, in terms of things being, in my opinion, worse than they were before, it’s less to do with what we get from browsers and more to do with how we choose to make things on the Web. We seem to have collectively decided to make things really complicated in terms of, I want to put something on the Web that used to be relatively straightforward.

I know there were all sorts of problems with the way we used to do it and maybe it didn’t scale so well, but we seem to have collectively decided that the barrier to entry to putting something on the Web requires loads of technologies, not browser technologies, but technologies that sit on our computers or sit on our servers. It’s great that we’ve got version control, build tools, automatic bundlers, and all this stuff, but the level of complexity is extremely high, it seems to me.

I know I’m slow and maybe that’s the reason I’m just not very good at picking this stuff up, but it seems to be objectively quite complex. That strikes me as strange because, like I was saying, you can do more with less these days in a browser. It’s easier than ever to build something interactive in a browser with quite minimal HTML, a bit of JavaScript, CSS, right? You can do loads with what you get out of the browser. Yet, we’ve decided to almost reinvent everything for ourselves.

Even though the browser will let us do all this really smart stuff, let’s reinvent it in JavaScript for ourselves. Let’s reinvent going from URL to URL. We’ll call it rooting, and we’ll do all that ourselves. We’ll do it all in JavaScript, and that means now we have to manage state, and so we’re keeping track of all this stuff.

It’s weird because it’s a choice to do that stuff. Yet, we’re acting as though it’s the default.

People are constantly saying, “Oh, well, expectations are different now.” I will say that’s true. People’s expectations of the Web are different, but not in the way that people mostly talk about it.

When people use that phrase, “Oh, people’s expectations of the Web are different now,” what they usually mean is, “Oh, people expect more from the Web. People expect the Web to be fast and interactive like native apps and stuff. I think that would be great if that were true, but my observation from talking to people is that people’s expectations of the Web have changed.

People expect the Web to be terrible. I talk to people and they’ve simply given up on the Web. Certainly, on mobile, they just try to avoid going on the Web.

Yes, people’s expectations of the Web have changed but not for the better. They’re associating the Web with bad experiences, with things being slow, with constantly being bombarded with, you know, sign up to my newsletter, accept cookies, dark patterns, all this stuff.

The solution to that is not, well, let’s throw more complicated toolchains, JavaScript libraries, and frameworks at it. The solution is to pull things back. How about if we didn’t have terrible user experiences that bombard people with stuff? How about if we just made websites using the bare minimum technology so that they’re fast and respond quickly?

Yet, weirdly, we’ve gotten into this cycle where people say, “Oh, people’s expectations of the Web are so high now that we must use all this complex technology,” which just ends up making the Web feel, frankly, even worse. From that perspective, things are in a pretty terrible state for the Web. Yet, like I said in terms of what you can do out of the box in a browser, just get a text editor and write some HTML, a bit of CSS, a bit of JavaScript; you can make amazing things straight out of the box that 10, 15 years ago we literally couldn’t have imagined.

What are the most important things for people coming into the industry to understand? Thinking about how to ensure the things they are building will be reliable and maintainable in the future?

I think the first thing to establish is that people learn in different ways. The answer to this question kind of depends on the person. I’ve experienced this myself, talking to students in, say, Codebar and stuff, is that some people really want to know why something is working, first. Give me the fundamentals. Give me almost a bit of theory but build things up from the fundamentals upwards until we’ve got a thing that works.

Other people, they don’t work that way. They say, “I want to build something as quickly as possible.” Okay, let’s start with a framework. Let’s create React App or something, something that gets you something straight away and then work backward from there.

I say, “Okay, but what’s actually going on here? Why does this work? What’s happening under the hood?”

There are two different ways of learning there. Neither is right and neither is wrong. There are just different ways.

I think the important thing is that, at some point, you end up with this kind of layered level of knowledge that you’ve got the fundaments in the grounding and then you can add things on top like a framework at the tippy top of that stack. Whether you start with the framework and work down to the fundamentals or start with the fundamentals and work up to the framework, I don’t think that matters as long as what you end up with is a nice rounded kind of stack of technologies.

Then, I think, what you learn over time, and I feel is something you could be told but you kind of have to just learn it yourself and experience it, is that the stuff further down, the fundamentals will change at a much slower pace and the stuff higher up, the abstractions, the frameworks, the tools, they will change at a faster pace. Once you know that, then it’s okay. Then that feeling of being overwhelmed, like, “Oh, there’s so much to learn,” you can start to filter it and figure out, “Well, where do I want to concentrate? Do I want to learn stuff that I know I will have to swap out in another year, two years, three years, or will I concentrate my time on this lower level fundamental stuff that will last for maybe decades, or do I split it? Do I dedicate some of my time to fundamentals and some of my time to the abstractions?”

I think the key thing is that you go in with your eyes open about the nature of the thing you’re learning. If I’m going to learn about HTML and, to a certain extent, CSS and stuff, then I will know this is knowledge that will last for quite a while. It’s not going to change too quickly. But if I’m learning about a framework, a build tool, or something like that, then I will say, “Okay. It’s fine that I’m learning this,” but I shouldn’t be under any illusions that this is going to be forever and not be surprised when, further down the line, people say, “Oh, you’re still using that framework? We don’t use that anymore. We use this other framework now,” right?

I think that’s the key thing is going in with your eyes open. It’s totally fine to study all the stuff, learn all the stuff, as long as you’re not disappointed, like, “Oh, I invested all my time in that framework and now nobody is using that framework anymore. We’ve all moved on to this other framework.”

There’s a phrase from DevOps where you talk about your servers. They say, treat your servers like cattle, not pets. Don’t get too attached to them.

I feel like that’s the case with a lot of the tools we use. I would consider frameworks and libraries to be tools. They’re tools. You use them to help you work faster, but don’t get too attached to them because they will change whereas, the more fundamental stuff, you can rely on.

Now, when I say fundamental stuff, to a certain extent I’m talking about the technology stuff like HTML. That moves at a slow pace. HTTP and how the Internet works, that’s not going to change very fast.

When I say fundamentals, I think you can go deeper than that even, and you can talk about philosophies, attitudes, and ways of approaching how to build something on the Web that’s completely agnostic to technologies. In other words, it’s like what your mindset is when you approach building something, what your priorities are, what you value. Those kinds of things can last for a very, very long time, longer than any technologies.

For example, over time, on the Web, I’ve come to realize that progressive enhancement, which is completely technology agnostic—it’s just a way of thinking—is a good long-term investment. Even as technologies come and go, this approach of thinking in a sort of layered way and building up from the most supported thing to least supported thing works really well no matter what the technology is that comes along.

When Ajax came along in 2005, I could take the progressive enhancement approach and apply it to Ajax. When responsive design came along in 2010, I could take progressive enhancement and apply it to responsive design. When progressive Web apps come along, whatever it happens to be, I can take this approach, this fundamental approach and apply it to whatever the new technology is. Those things tend to be really long-lasting. Those kinds of approaches, almost strategies I guess, are things that can last a long time.

You should always be questioning them. You should always be saying, “Is this still relevant? Does this still work in this situation? Does it still apply?” Over a long time period, you start to get an answer to that. It’s like, “Yeah, actually, it’s funny. Even over 20 years, this particular strategy works really well,” whereas some other strategy that worked well 15 years ago, it turns out, just doesn’t even apply today because some technology has made it obsolete.

Yeah, fundamental things aren’t necessarily technologies. I think a Web developer is well versed in getting to grips with those fundamental things but, at the same time, I’m not sure if you could learn those first. I’m not sure if you could be like, “Okay, we’re going to learn about these fundamental things without touching a line of code.” You kind of have to learn them for yourself by doing it and learning over time, I think.

Do you think frameworks, for example, will be replaced by the establishment of long-lasting Web components with CSS routines where we can adjust everything? Is this the world we’re moving toward or is it going to stay simple after all?

Yes, absolutely, the things that people are pushing the envelope with, in terms of frameworks today, will become the standards of tomorrow. I think I would put good money on that because I’ve seen it happen. I’ve seen it happen in the past, generally.

It’s usually in JavaScript that we figure something out, we figure out what we want, and we make it work in JavaScript first. If it’s a really powerful idea that solves a common problem, it will find its way further down.

The classic example, early on, I’m talking in the ’90s now, the first pieces of JavaScript were things like doing image rollovers. Now we don’t need JavaScript for that because we use hover in CSS. It’s such a common use case, it moved down into the declarative layer.

The same with form validation. You have to write your own form validation. Now you can just do required in HTML and stuff like that. This pattern plays out over and over again. With responsive images, we figured out what we wanted in JavaScript and then we got it in HTML with pictures.

Yes, I think the goal of any good framework or library should be to make itself redundant. A classic example of this would be jQuery. You don’t need jQuery today because all the stuff that jQuery did for you like using CSS selectors to find DOM nodes, you can do that now in the browser using querySelector, querySelectorAll. But of course, the only reason why querySelector exists is because jQuery proved it was powerful and people wanted it.

I think, absolutely, a lot of the things that people are currently using frameworks and libraries for will become part of the standard, whether that has to do with the idea of a virtual DOM, state management, managing page transitions, giving us control over that. Yes, absolutely, that will find its way.

Now, whether the specific implementations will be these things like Web components, Houdini, and stuff like that, that’s interesting. We’ll see how that plays out. That’s all part of this bigger idea of the extensible Web where, in the past, we would get specific things like, here is the picture element, here is this new JavaScript API or whatever, here is querySelector. Whereas now, we’ve sort of been given, okay, here are the nuts and bolts of how a browser works. You build a solution and then we’ll see what happens. That’s an interesting idea.

I guess the theory is then that, okay, let’s say we get Web components, we get Houdini. Now we all start building our own widgets and we all start building our own CSS functions. The theory is that the ones that are really popular and really goodwill then get standardized and end up in the standards.

I’m not sure if that’s actually going to happen because I wonder what a standards body or browser maker would actually say is, “Oh, well, we don’t need to make it part of the standard because everyone can just use the Web component, everyone can just use this Houdini thing,” right? We’ll see whether that works out.

I wonder if it’ll end up maybe like the situation with jQuery plugins. I mentioned that jQuery was great, it showed this is what people want, and it ended up as a standard. As well as jQuery the library, you also had jQuery plugins, the ecosystem where everybody built a thousand different carousels, a thousand different widgets. There was no quality control and you couldn’t figure out which was the right one to use. I worry that might be where we end up with things like Web components, Houdini, and stuff like that. But it’s an interesting idea, this extensible Web thing.

How will we build? How will the workflow or the tooling change and evolve as we move forward?

Well, that’s up to us. These things are created by people, so that’s something to be aware of. When people come to the Web think, “Oh, what should I learn? What’s the tool? What’s the methodology? How will we be building websites?” It’s almost like, what horse should I be backing here? What’s a safe bet?

You’ve got to step back and realize these things aren’t handed down from heaven as some kind of decision has been made and then passed on to us. We make those decisions. We decide how the Web gets built. There’s no central authority on this stuff. We collectively decide it.

You can choose how the future of Web development is going to look. You could choose what a workflow is going to look like that works for you and works for other people.

The Web is super flexible. You can choose to build in this layered way that I’ve talked about, progressive enhancement, very resilient way of working, but you don’t have to. The Web doesn’t mandate that you work that way. You could choose to build in a way that you just do everything in JavaScript and make JavaScript do the rooting, the DOM, and everything in JavaScript.

It’s a choice. It’s not something that, oh, in the future, we will all do this; in the future, we will all do that. In the future, you will make a choice about how you want to build.

I think, too often, though, when we’re making those decisions of how should I build or what’s the best way to build something on the Web, I worry that sometimes we think about it a bit too much from our perspective. What’s the best way for me to build on the Web? What’s going to make things easiest for me as a developer?

I don’t want to make things hard for us. I don’t want life to be difficult, but I do think our priorities should actually be what’s going to make things better for the user, even if that means more work from us.

If you’re getting paid, if you’re getting a paycheck to make things on the Web—then again, kind of going back to responsibility—it’s not about you now. You have a duty of care to the people who will be using the thing you’re building. Decisions about how to build on the Web shouldn’t just be made according to what you like, what you think is nice for you, what makes your life easy, what saves you typing, but should be more informed by what’s going to be better for users, what’s going to be more resilient, what’s going to leave nobody behind, you know, something that’s available to everyone.

I know I’m talking a lot in abstractions and vagaries, but the talk at View Source will go into a little more detail.

People are often disappointed in the state of the Web today. How do you see the Web evolving over the years? Do you think that privacy and ethics will become a standard?

I think the first thing to establish is that I don’t want to paint too rosy a picture of how things were in the past. There have always been problems. It’s just that we might have different problems today.

I remember the days of literal pop-up windows or pop-under windows, things like that, really annoying things that eventually browsers had to come in and kind of stamp down on that stuff. That’s sort of happening today as well with some of the egregious tracking and surveillance you see Safari and Firefox taking steps to limit that.

In the past, I would have said, “Oh, we need to figure this out. We need to almost self-regulate,” you know, before it’s too late. At this point, I think, “No, it is too late,” and regulation is coming. GDPR is a first step in that and there will be more.

We deserve it. We had our chance to figure this stuff out for ourselves and do the right thing. We blew it, and things are really bad when it comes to surveillance and tracking.

A lot of the business models seem to be predicated on tracking. I’m saying tracking here, not advertising. Advertising isn’t the issue here. It’s specifically tracking.

It’s a bit of a shame that we talk about ad blockers as a software. Most people are not blocking ads. What they’re blocking is tracking. Again, the same way that browsers had to kind of step in and stop popups and pop-under windows, now we see ad blockers, tracking blockers stepping in to solve this.

We get this kind of battle, right? It’s almost like an arms race that’s been going on. I think regulation is going to come in on top of that. Guaranteed it’s going to happen.

You’re right; the fundamental business models in use today are kind of at odds with privacy and surveillance, so they might need to change. Although, I don’t think advertising requires tracking. I know a lot of people talk as though it does. People talk about, “Oh, you can’t have advertising without a tracking link.” You absolutely can. Sponsorship, other kinds of advertising absolutely work.

The other thing is that tracking is not very good. If I’m advertised to with something that absolutely suits my needs then it kind of ceases to be advertising. It just becomes useful, right? That’s not what I experience. What I experience is just really badly targeted things. It’s not even like the tracking works. Yet, people claim tracking is essential.

Anyway, when I say business models need to change, I don’t mean advertising. I think advertising is actually a reasonable business model for some kinds of services. That connection between advertising and tracking, that needs to be severed.

Some people think that’s impossible. They say, “No, it’s just a law of nature that those two things go together.” That’s not true. We choose that. 
The other thing to remember is that we sometimes look around to see how things are today and we can’t imagine it could be any different. We see one dominant search engine and so we think there could only ever be one dominant search engine, but that’s not true. That’s just the way things have turned out. We see a big social network like Facebook and we think, “Oh, there could ever be one big social network.” Again, that’s just the way things have turned out in our situation.

I think the worst thing we can do is assume things are inevitable and it’s inevitable that things end up that way. That’s particularly true when it comes to surveillance and tracking and things that are antiprivacy to say, “Well, that’s just the way it is. It’s inevitable and it couldn’t be any other way.” I think the first step is that we have to have the imagination to think about how things could be different, how things could have turned out differently, and then work towards making that a reality.

Also, this is a huge opportunity. People are clearly fed up with the tracking. They’re fed up with the surveillance. They don’t mind the advertising. There is a separation there. There is an opportunity here to take on these big organizations who literally can’t change their business model.

Someone like Google, the idea of tracking and surveillance is kind of intrinsically linked to their core business model. That gives a huge opportunity. You can see Apple already starting to exploit this opportunity, but other people, too, where you can make privacy and lack of tracking your selling point. It’s a way for a small player to suddenly maybe disrupt the incumbents because the incumbents are so reliant on tracking.

You can’t take on Facebook by trying to be another Facebook, but you can take on Facebook by being what Facebook can’t do. Not what Facebook won’t do, what Facebook literally can’t do. There’s actually a big opportunity there.

Yeah, when we talk about the good old days of keeping track of things, blogs, I kind of share that because I remember the good old days as well. But I’ll say I see a bit of a resurgence as well. Enough people are getting fed up with just posting on silos like Twitter, Facebook, and stuff that I see more and more people launching their own websites again and publishing there. I hope we’ll see more of that.

What are you most excited about on the Web these days?

Yeah, this is an interesting question because it’s happened over and over again over the course of my career, about 20 years now, where I’ll think, like, “Oh, there’s nothing really exciting me,” and then something comes along and I get, ooh, really excited. Almost kind of puttering along when CSS came along, “Oh, this is really interesting.” Then, years later, Ajax, like, “Ah, this is really interesting.”

I think currently service workers are the things that get me excited, get me thinking about, oh, the potential for what the Web could be. The potential for the user experience on the Web is huge. I don’t even think the challenges are technological because it’s pretty straightforward using service workers.

It’s more changing people’s expectations of the Web, the idea that, oh, you should be able to open a browser or hit a bookmark and have something happen even if you don’t have an Internet connection or even if you are on a crappy network that things could still be quite reliable. That’s such a fundamental change and that gets me very, very excited. It’s also, obviously, a huge challenge to change that.

I have to say, over a long enough time period, the things that I start to think about start to be less and less about specific technologies and more and more about just the Web, in general, and the people making the Web.

I certainly have fears for the Web. They aren’t so much around technologies, like, “Oh, will one particular browser make or dominate,” or, “Will one particular framework be the only technology around?” Those things are concerning. It’s more about, “Will the idea of being able to make for the Web start to get reduced down to an elite kind of priesthood of a certain kind of person?” Frankly, the kind of person who looks like me, right? White, male, privileged, European. If we’re the only people who get to make for the Web, that will be terrible.

I think the real potential of the Web and the promise of the Web from the early days was that it’s for anyone. Anybody should be able to not just use the Web and consume it, but anyone should be able to add to it and build for it.

The thing that actually motivates me now is less about a specific technology and more about how can I try and get a more diverse range of people making the Web, making their own careers out of making for the Web rather than it being reduced, reduced, reduced to a certain kind of person. When I’m done with all this, if I look around and all the other people making websites look just like me, then I think we’ll have failed.

Wednesday, November 27th, 2019

Why I’m going back to New Adventures | Andrew Travers

The opening of this blog post warned the cockles of my heart:

I have a rule about conferences: go once.

Like all rules, it can be broken — usually when Jeremy Keith is involved — but not often.

Awww! That’s so nice!

Sunday, June 9th, 2019

VOCAL

Each typeface highlights a piece of history from a specific underrepresented race, ethnicity, or gender—from the Women’s Suffrage Movement in Argentina to the Civil Rights Movement in America.

Thursday, January 31st, 2019

HTML, CSS and our vanishing industry entry points

This!

When we talk about HTML and CSS these discussions impact the entry point into this profession. Whether front or backend, many of us without a computer science background are here because of the ease of starting to write HTML and CSS. The magic of seeing our code do stuff on a real live webpage! We have already lost many of the entry points that we had. We don’t have the forums of parents teaching each other HTML and CSS, in order to make a family album. Those people now use Facebook, or perhaps run a blog on wordpress.com or SquareSpace with a standard template. We don’t have people customising their MySpace profile, or learning HTML via Neopets. We don’t have the people, usually women, entering the industry because they needed to learn HTML during that period when an organisation’s website was deemed part of the duties of the administrator.

I agree with every single word Rachel has written.

I care not a whit what tools or frameworks, or languages you use to build something on the web. But I really care deeply when particular tools, frameworks, or languages become mandatory for even getting a foot in the door.

This is for everyone.

I might be the “old guard” but if you think I’m incapable of learning React, or another framework, and am defending my way of working because of this, please get over yourself. However, 22 year old me would have looked at those things and run away. 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 have plenty of fight left in me to stand up against that.