A good range of answers for this year’s question, overlapping a bit with 2011’s What scientific concept would improve everybody’s cognitive toolkit?
Wednesday, January 11th, 2017
Thursday, February 4th, 2016
Microsoft are officially on board with implementing Service Workers in Edge:
Roadmap Priority: High — We intend to begin development soon.
Monday, September 14th, 2015
John expands on just one part of his superbly dense and entertaining dConstruct talk.
Monday, July 13th, 2015
Here’s the video of the panel I participated in at Edge conference, expertly moderated by Lyza.
Thanks to the video editing, you can’t see the face I’m making when the guy from Facebook talks about user-agent sniffing as a totally cool and reliable way of working.
Tuesday, June 30th, 2015
I really enjoyed last year’s Edge conference so I made sure not to miss this year’s event, which took place last weekend.
The format was a little different this time ‘round. Last year the whole day was taken up with panels. Now, panels are often rambling, cringeworthy affairs, but Edge Conf is one of the few events that does panels well: they’re run on a tight schedule and put together with lots of work in advance. At this year’s Edge, the morning was taken up with these tightly-run panels as usual, but the afternoon consisted of more Barcamp-like breakout sessions.
I’ve got to be honest: I don’t think the new format worked that well. The breakout sessions didn’t have the true flexibility that you get with an unconference schedule, so there was no opportunity to merge similarly-themed sessions. There was, for example, a session on components at the same time as a session on accessibility in web components.
That highlights the other issue: FOMO. I’m really not a fan of multi-track events; there were so many sessions that sounded really interesting, but I couldn’t clone myself and go to all of them at once.
But, like I said, the first half of the day was taken up with four sequential (rather than parallel) panels and they were all excellent. All of the moderators did a fantastic job, and I was fortunate enough to sit in on the progressive enhancement panel expertly moderated by Lyza.
The event is called Edge for a reason. There is a rarefied atmosphere—and not just because of the broken-down air conditioning. This is a room full of developers on the cutting edge of web development technologies. Being at Edge Conf means being in a bubble. And being in a bubble is absolutely fine as long as you’re aware you’re in a bubble. It would be problematic if anyone were to mistake the audience and the discussions at Edge as being in any way representative of typical working web devs.
One of the most insightful comments of the day came from Christian who said, “Yes, but this is Edge Conf.” You’re going to need some context for that quote, so here it is…
On the web components panel that Christian was moderating, Alex was making a point about the ubiquity of tools—”Tooling was save you”, he said—and he asked for a show of hands from the audience on who was not using some particular tooling technology; transpilers, package managers, build tools, I can’t remember the specific question. Nobody put their hand up. “See?” asked Alex. “Yes”, said Christian, “but this is Edge Conf.”
Now, while I wasn’t keen on the format of the afternoon with its multiple simultaneous breakout sessions, that doesn’t mean I didn’t enjoy the ones I plumped for. Quite the opposite. The last breakout session of the day, again expertly moderated by Lyza, was particularly great.
- It’s not about making all of your functionality available; it’s making your core functionality available: everything else can be considered an enhancement and it’s perfectly fine if not everyone gets that enhancement.
And yet the misunderstanding persists. For that reason, most of the people in the discussion at Edge Conf were in favour of simply dropping the term progressive enhancement and instead focusing on terms like availability and access. Tim writes:
I’m not sure what we call it now. Maybe we do need another term to get people to move away from the “progressive enhancement = working without JS” baggage that distracts from the real goal.
And Stuart writes:
So I’m not going to be talking about progressive enhancement any more. I’m going to be talking about availability. About reach. About my web apps being for everyone even when the universe tries to get in the way.
But Jason writes:
I completely disagree that we should change nomenclature because there exists some small segment of Web designers unwilling to expand their development toolbox. I think progressive enhancement—the term—remains useful, descriptive, and appropriate.
I’m torn. On the one hand, I agree with Jason. The term “progressive enhancement” is a great descriptor. But on the other hand, I don’t want to end up like that guy who’s made it his life’s work to change every instance of the phrase “comprises of” to “comprises” (or “consists of”) on Wikipedia. Technically, he’s correct. But it doesn’t sound like a fun way to spend your days.
I guess my worry is, if I write an article or give a presentation, and I title it something to do with progressive enhancement, am I going to alienate and put off the very audience I’m trying to reach? But if I title it something else, am I tricking people?
Words are hard.
Sunday, June 28th, 2015
Stuart writes up his thoughts on progressive enhancement following the great discussions at Edge Conf:
So I’m not going to be talking about progressive enhancement any more. I’m going to be talking about availability. About reach. About my web apps being for everyone even when the universe tries to stop it.
Saturday, June 27th, 2015
100 words 097
It’s the weekend …and I got up at the crack of dawn to head to London. Yes, on this beautiful sunny day, I elected to take the commuter train up to the big city to spend the day trapped inside a building where the air conditioning crapped out. Sweaty!
But it was worth it. I was at the Edge conference, which is always an intense dose of condensed nerdery. This year I participated in one of the panels: a discussion on progressive enhancement expertly moderated by Lyza. She also led a break-out session on the same topic later on.
Sunday, March 29th, 2015
100 words 007
I’m staying at the Edgewater hotel in Seattle, an unusual structure that is literally on the water, giving it a nautical atmosphere. The views out on the Puget Sound are quite lovely.
Inside, the hotel has more of a Twin Peaks vibe. It feels less like a hotel and more like a lodge.
The hotel is clearly proud of the many rock stars it has hosted over the years. As you settle into your cosy room, you can imagine what it was like when the Beatles were fishing from their balcony, or Led Zeppelin were doing unspeakable things with mudsharks.
Tuesday, January 20th, 2015
A profile of the wonderful Internet Archive.
No one believes any longer, if anyone ever did, that “if it’s on the Web it must be true,” but a lot of people do believe that if it’s on the Web it will stay on the Web. Chances are, though, that it actually won’t.
Brewster Kahle is my hero.
Kahle is a digital utopian attempting to stave off a digital dystopia. He views the Web as a giant library, and doesn’t think it ought to belong to a corporation, or that anyone should have to go through a portal owned by a corporation in order to read it. “We are building a library that is us,” he says, “and it is ours.”
Saturday, September 13th, 2014
The text of Mandy’s astounding dConstruct talk.
Thursday, August 14th, 2014
How computers work:
One day, a man name Alan Turing found a magic lamp, and rubbed it. Out popped a genie, and Turing wished for infinite wishes. Then we killed him for being gay, but we still have the wishes.
Then we networked computers together:
The network is ultimately not doing a favor for those in power, even if they think they’ve mastered it for now. It increases their power a bit, it increases the power of individuals immeasurably. We just have to learn to live in the age of networks.
We are all nodes in many networks. This is a beautiful description of how one of those networks operates.
Friday, May 16th, 2014
I guess it goes without saying at this point, but this piece from Frank is beautiful and thought-provoking.
This part in particular touched on some things I’ve been thinking about lately:
Design’s golden calf is simplicity. Speaking as someone who sees, makes, and uses design each and every day, I am tired of simple things. Simple things are weak. They are limited. They are boring. What I truly want is clarity. Give me clear and evident things over simple things. Make me things that presume and honor my intelligence. Shun seamlessness. It is another false token. Make me things that are full of seams, because if you give me a seam and I pull the thread, I get to see how the whole world is stitched together. Give me some credit. Show me you trust me.
Sunday, March 23rd, 2014
Notes from the edge
I went up to London for the Edge Conference on Friday. It’s not your typical conference. Instead of talks, there are panels, but not the crap kind, where nobody says anything of interest: these panels are ruthlessly curated and prepared. There’s lots of audience interaction too, but again, not the crap kind, where one or two people dominate the discussion with their own pet topics: questions are submitted ahead of time, and then you are called upon to ask it at the right moment. It’s like Question Time for the web.
The first panel was on that hottest of topics: Web Components. Peter Gasston kicked it off with a superb introduction to the subject. Have a read of his equally-excellent article in Smashing Magazine to get the gist.
Needless to say, this panel covered similar ground to the TAG meetup I attended a little while back, and left me with similar feelings: I’m equal parts excited and nervous; optimistic and worried. If Web Components work out, and we get a kind emergent semantics of UI widgets, it’ll be a huge leap forward for the web. But if we end up with a Tower of Babel, things could get very messy indeed. We’ll probably get both at once. And I think that’ll be (mostly) okay.
I butted into the discussion when the topic of accessibility came up. I was a little worried about what I was hearing, which was mainly, “Oh, ARIA takes care of the accesibility.” I felt like Web Components were passing the buck to ARIA, which would be fine if it weren’t for the fact that ARIA can’t cover all the possible use-cases of Web Components.
Let me set the scene for Web Components…
Historically, HTML has had a limited vocubalary for expressing interface widgets—mostly a bunch of specialised form fields like, say, the
select element. The plus side is that there’s a consensus of understanding among the browsers, so you don’t have to explain what a
select element does; the browsers already know. The downside is that whenever we want to add a new interface element like
input type="range", it takes time to get into browsers and through the standards process. Web Components allow you to conjure up interface elements, and you don’t have to lobby browser makers or standards groups in order to make browsers understand your newly-minted element: you provide all the behavioural and styling instructions in one bundle.
select element because the browser knows what it is and can expose that knowledge to the assistive technology. If we’re going to start making up our own interface elements, we now have to take on the responsibility of providing that information to assistive technology.
That’s not a criticism of ARIA: that’s the way it was designed. It’s a reactionary technology, designed to plug the gaps where the native semantics of HTML just don’t cut it. The vocabulary of ARIA was created by looking at the kinds of interface elements people are making—tabs, sliders, and so on. That’s fine, but it can’t scale to keep pace with Web Components.
The problem that Web Components solve—the fact that it currently takes too long to get a new interface element into browsers—doesn’t have a corresponding solution when it comes to accessibility hooks. Just adding more and more predefined ARIA roles won’t cut it—we need some kind of extensible accessibility that matches the expressive power of Web Components. We don’t need a bigger vocabulary in ARIA, we need a way to define our own vocabulary—an extensible ARIA, if you will.
Hmmm… I’m still not sure I’m explaining myself very well.
Anyway, I just want to make sure that accessibility doesn’t get left behind (again!) in our rush to create a new solution to our current problems. With Web Components still in their infancy, this feels like the right time to raise these concerns.
That highlights another issue, one that Nicole picked up on. It’s really important that the extensible web community and the accessibility community talk to each other.
Frankly, the accessibility community can be its own worst enemy sometimes. So don’t get me wrong: I’m not bringing up my concerns about the accessibility of Web Components in order to cry “fail!”—I just want to make sure that it’s on the table (and I’m glad that Alex is one of the people driving Web Components—his history with Dojo reassures me that we can push the boundaries of interface widgets on the web without leaving accessibility behind).
Anyway …that’s enough about that. I haven’t mentioned all the other great discussions that took place at Edge Conference.
The Web Components panel was followed by a panel on developer tools. This was dominated by representatives from different browsers, each touting their own set of in-browser tools. But the person who I really wanted to rally behind was Kenneth Auchenberg. He quite rightly asks why our developer tools and our text editors are two different apps. And rather than try to put text editors into developer tools, what we really want is to pull developer tools into our text editors …all the developer tools from all the browsers, not just one set of developer tools from one specific browser.
I had my hand up to jump into the discussion towards the end, but time ran out so I didn’t get a chance. Paul came over afterwards and asked what I was going to say. Here’s what I told him…
I’m fascinated by the social dynamics around how browsers get made. This is an area where different companies are simultaneously collaborating and competing.
Broadly speaking, the feature set of a web browser can be divided into two buckets:
In the other bucket, you’ve got all the stuff that browsers compete against each other with: speed, security, the user interface, etc. A lot of this takes place behind closed doors, and that’s fine. There’s no real need for browser makers to collaborate on this stuff, and it could even hurt their competetive advantage if they did collaborate.
But here’s the problem; developer tools seem to be coming out of that second bucket instead of the first. There doesn’t seem to be much communication between the browser makers on developer tools. That’s fine if you see developer tools as an opportunity for competition, but it’s lousy if you see developer tools as an opportunity for interoperability.
This is why Kenneth’s work is so important. He’s crying out for more interoperability between browsers when it comes to developer tools. Why can’t they all use the same low-level APIs under the hood? Then they can still compete on how pretty their dev tools look, without making life miserable for developers who want to move quickly between browsers.
As painful as it might be, I think that browser makers should get together in some semi-formalised way to standardise this stuff. I don’t think that the W3C or the WHATWG are necessarily the right places for this kind of standardisation, but any kind of official cooperation would be good.
The panel on build processes for front-end development kicked off with Gareth saying a few words. Some of those words included the sentence:
Make is probably older than you.
Cue glares from me and Scott.
Gareth also said that making websites means making software. We’re all making software—live with it.
This made me nervous. I’ve always felt that one of the great strengths of the web has been its low barrier to entry. The idea of a web that can only be made by qualified software developers doesn’t sound like a good thing to me.
Fortunately, things got cleared up later on. Somebody else asked a question about whether the barrier to entry was being raised by the complexity of tools like preprocessors, compilers, and transpilers. The consensus of the panel was that these are power tools for power users. So if someone were learning to make a website from scratch, you wouldn’t start them off with, say, Sass, without first learning CSS.
It was a fun panel, made particulary enjoyable by the presence of Kyle Simpson. I like the cut of his jib. Alas, I didn’t get the chance to tell him that in person. I had to duck out of the afternoon’s panels to get back to Brighton due to unforeseen family circumstances. But I did manage to catch some of the later panels on the live stream.
A common thread I noticed amongst many of the panels was a strong bias for decantralisation, rather than collaboration. That was most evident with Web Components—the whole point is that you can make up your own particular solution rather than waiting for a standards body. But it was also evident in the Developer Tools line-up, where each browser maker is reinventing the same wheels. And when it came to Build Process, it struck me that everyone is scratching their own itch instead of getting together to work on an itch solution.
There’s nothing wrong with that kind of Darwinian approach to solving our problems, but it does seem a bit wasteful. Mairead Buchan was at Edge Conference too and she noticed the same trend. Sounds like she’s going to do something about it too.
Monday, May 13th, 2013
This is a breath of fresh air: a blogging platform that promises to keep its URLs online in perpetuity.
Monday, September 24th, 2012
Oh, dear. Adobe Shadow gets a new name and a hefty price tag. Yesterday it was free. Today it is $119.88 per year. It’s useful but it’s not that useful.
So, lazy web, who’s working on an open-source alternative?
Monday, July 2nd, 2012
Vannevar Bush’s original 1945 motherlode of hypertext.
Wednesday, March 28th, 2012
I like Cennydd’s thoughts on the fundamental difference between skill and process:
Skilled people without a process will always find a way to get things done. Skill begets process. But process doesn’t beget skill.
Sunday, March 18th, 2012
A lovely piece of mainstream news reporting on Galaxy Zoo and the other Zooniverse projects, and the broader role of Citizen Science.
Tuesday, September 13th, 2011
This is worth reading just for Andy Budd’s answer alone. Priceless.
I think I’m having a flashback and am in need of a bit of a lie down. Wake me up when 1998 is over. I didn’t like it much the first time around, so I’m pretty sure it’s going to suck now.
Saturday, January 29th, 2011
A proto-wikipedia from January 1749.