Hi, greetings and welcome to virtual TPAC.

My name's Dan Appelquist, I work for Samsung and I'm also the co-chair of the W3C TAG. And today's talk is going to be about the work of the W3C TAG, the Technical Architecture Group, and also some work that we've been putting into something called the Design Principles which is a document that we'd really like everyone to take a look at.

So, first of all, what is the TAG?

The TAG is a special group that's chartered to document, and build consensus around principles of Web architecture, and to interpret and clarify these principles when necessary to resolve issues involving general Web architecture that are brought to the TAG.

And to help coordinate cross-technology architecture developments inside and outside of W3C.

So we also work with organizations such as TC39, WHATWG, IETF on topics that involve Web architecture generally.

We have six elected participants, they're elected by the Advisory Committee.

We have three appointed participants, appointed by the director, and we have one permanent chair who is Tim and one staff contact, which is Yves.

Apart from myself, we have Rossen from Microsoft.

David Barron an Invited Expert.

Hadley Beeman Invited Expert.

Alex Boxhall from Google.

Ken Christiansen from Intel.

Yves Lafon, he's our staff contact.

Peter Linss also an Invited Expert, and my co-chair Sangwhan Moon from Odd Concepts, and Tess O'Connor from Apple.

So the current work of the TAG, as if you've seen any of these presentations before is around, hasn't changed, it's around pondering deep questions about the web, but we try and focus on writing stuff.

And in particular I'm going to talk about writing design principles today.

But we also do design reviews, and that is probably the bread and butter of our work.

It's most of the work that we do is in design reviews and that, by which I mean reviewing other people's work.

We also do joint work with other groups, and we play a role in cross organization liaisons.

And although we haven't been doing this for the past year we try and do developer community engagement as well.

So how do we TAG during a pandemic?

This is one thing that I think all groups might be interested in hearing.

How are we working?

How does W3C work in general during a pandemic?

Well, I can say that the TAG is continuing its cadence of four video calls a week, which might sound like a lot but three of those are breakout calls where we have a subset of people that depending on what time zone they're in.

And then we have one plenary call where we all try, and be on the call and it's on those calls that we try and take decisions and make resolutions, and that kind of thing.

We've shifted to a virtual face-to-face.

We just held our second virtual face-to-face which has a four day schedule, that's comprised of 18 breakout sessions across three times zone groups.

If that sounds complex, it is.

We probably spend the week before the face-to-face organizing the agenda for the face-to-face.

If anybody's interested in learning about the logistics that we put in or the organization that we put in place in order to set that agenda, please come talk to me.

I'd be happy to talk you through it.

I'm not sure whether you will want to use the same process that we do.

So, but in terms of conferencing and communication, we have a combination of WebRTC-based tools.

So we use Jisti.org for our general calls.

And we use WhereBy which is another WebRTC-based service for our face-to-face because it allows us to have a little bit more security on our rooms.

And we also use CryptPad for minutes, and we use Slack for general communication out of the time of our calls, and for sending your URLs back and forth to each other.

So I want to talk briefly about the Design Reviews.

As I said, this is the TAG's heartbeat.

You can find all of our design reviews on GitHub in the design reviews iSH repo.

We request that people request a TAG review early in the design process, because we really want to, we really want to try and bring that benefit to you during the process of when you're thinking about the design for a new specification.

When you make a review a request from us, we really ask that you take a look at our design principles document, and I'm going to talk about the design principles document briefly in a second.

And we also ask that you write an explainer.

So you can find more about how we work, and what the TAG review process is all about at the URL that I've listed below about our TAG work mode.

And I just wanted to briefly talk a little bit more about what is an explainer because this is a topic that comes up a lot, and it's something that I think some groups have had a little bit of confusion about.

So first of all, an explainer is a living document.

It's not the spec itself, it's a living document that describes the current state of your proposed web platform feature or a collection of features.

It helps to facilitate multi-stakeholder discussion.

So the TAG is one of those stakeholders but it's not the only stakeholder and consensus-building.

So it's something that you can send to people to help explain what it is that you're working on.

It starts with the user-facing problem that this specification addresses.

And this comes back to user need.

And a lot of what the TAG has been focusing on recently is codifying how user need fits into the design process, and should be at the heart of the thinking when we are bringing new features to the web.

Its intended audience is other web technologists, really.

So you can assume kind of some knowledge of web technology, and platform, but they might not be familiar with the problem space that you're addressing.

So when you're writing an explainer, it's really helpful if you, again, start with the user need and also come at it from the perspective that the people that you're talking to may not know about your particular problem space.

They might not know about, for instance, notifications if you're talking about notifications.

So they might not know about the particular technology domain that your spec addresses.

So anyway, that's kind of a very brief rundown of what we hope from an explainer.

I think one of the key topics or one of the key messages that I'd like to bring across is that the explainer is not for the TAG.

The explainer is for you.

And the reason that we request an explainer, when you request a TAG review is that we think it's good practice.

And it also helps us to execute the review because we can immediately take a look at the explainer, and see what we're talking about and what we need to what we need to think about getting into the mind space of the specification that we're reviewing.

But in general, it's good practice, and we really encourage you to think about that.

And please come talk to us, if you have any questions about explainers.

You can find the current work of the TAG at tag.w3.org.

And you can also also visit our meetings repo.

We put all of our agendas and minutes in our meetings repo, and that's at github.com/w3ctag/meetings.

And all minutes are linked from our agenda.

So I wanted to, last thing I'm going to talk about is Web Platform Design Principles.

This is a document which has been recently renamed from Client-side API Design principles, that's because the scope has increased considerably in the past year.

So a lot of the feedback that we've received over the years from the TAG is or to the TAG is when are you going to do a SQL to the architecture of the www document?

When are you going to do a SQL or when are you going to do an addendum?

And we really have not felt that that's necessary because we're really trying to address a different set of problems right now.

What we have been doing in the context of our design reviews, in the context of being a kind of, I hesitate to use the word design authority but that's kind of the idea for W3C is to codify a lot of those principles that we've been thinking about, and put them down into a design principles document.

That started off with the name Client-side API Design Principles.

And as I said, recently, we've expanded the scope.

So one of the questions that we're attempting to answer I think with this document is what differentiates the web from other platforms and systems?

Which I think is a really important issue to think about.

And we don't have a single answer but I think some of the principles that are in this document and the way that we've linked back to our ethical web principles document as well from it show the way forward for what those differentiators are.

And the other question is how can we best design new technologies for the web?

And that's really where we think this document plays an important role.

When you're thinking about adding a new technology to the web, we've laid out a whole bunch of things that you should be thinking about, and design principles for different aspects of that technology.

The topic areas are many.

They range from basic principles behind the design of Web APIs, to CSS, to API Designs Across Languages.

JavaScript Language, Event Design, Types in Units.

Principles around Operating System and Device Wrapper APIs Other API Design Considerations, and general writing guidelines.

Writing good specifications and how to name things.

So we haven't left the single hardest problem in computer science out.

I wanted to highlight two key design principles which are things that we have that one of which, what is this putting user needs first?

And again, I talked a little bit about user needs, and how important they are from a design perspective.

And this is something that we've really brought in from the HTML design principles which is, which now is really informing all of our thinking around how we think about design principles for the web.

So this has also been called the priority of constituents and just to summarize, put user needs before the needs of implementers, before the needs of developers, sorry, before the needs of the user agent developers, and before the needs of spec writers, which again, come before the needs of theoretical purists.

So we think that's pretty important, and it informs the rest of the document as well.

The other thing that I really wanted to highlight as a kind of general principle for the web, and an example of the kind of general principles for the web is this safe to browse principle.

So it should be safe to visit a webpage.

I think that's one of the things that we think about when we think about what differentiates the web from other platforms, is this safety factor.

And that, again, trickles down into many other types of decisions that you might make when you're building new technologies to the web around privacy, around data, around security.

So again, those are the types of founding principles that we're looking at, when we're looking at design principles for the web.

There are many others.

There is a lot more detail in this document that I don't have time to go into today.

I would really encourage you to take a look.

Thank you.

That's it for me.

I really appreciate your time.

And I look forward to meeting you in W3C virtual TPAC space, and hopefully at a face-to-face meeting in the future.

Thank you.