Go to content
A talk from Web Summer Camp sharing our experience of working on the W3C redesign project

I was invited to speak at NetGen’s Web Summer Camp 2022, which took place on 1st and 2nd September 2022 at Amadria Park, Šibenik, Croatia.

The conference was an amazing experience, held in a beautiful Croatian beach hotel. NetGen were excellent hosts. It was great to chat to industry experts such as Stephen Hay, Harry Roberts and others, learning about web performance, design thinking, data privacy, AI and other topics. The conference was organised into web and developer tracks which covered UX, PHP, Symfony, and Javascript.

I’d firmly recommend Web Summer Camp. It’s a friendly environment, lots to learn, great food, a beautiful location, and we all had a very enjoyable boat trip on the last day to the small island of Krapanj, famous for it’s sea sponge industry!

A group of people on a sunny day standing in front of a boat listening to a tour guide on the Web Summer Camp boat trip to the small Croatian island Krapanj.

My talk was a case study on the w3.org redesign. I discussed some of the unique challenges the team faced including the CSS approach, how we tackled accessibility, creating a design system, and working in the open. And I shared insights on how we grew as an agency thanks to this amazing opportunity to work with the industry standard-setters.

The talk video and transcript appear below. Janus Boye MC’d the web track at Web Summer Camp.


Insight from the W3C website redesign and the experience of working with the industry standard-setters. Simon Jones
Hello, I’m Simon. It’s very nice to see everyone here today. It’s my first time in Croatia. It’s a lovely country to visit, somewhere I want to bring my family back to. It’s my first time of going to a conference with a beach outside which is awesome. So…

[audience laughs]

Video of Simon speaking is a thumbnail at the bottom right of the screen throughout the presentation.

How we grew as an agency by redesigning w3.org. Simon Jones, Studio 24.

I run a digital agency in the UK called Studio 24. We do things like digital strategy, we design and build web apps and websites for our clients. And we have a really strong focus on inclusive design and accessibility within the agency.

We’re based in Cambridge and this is the office but we have a few staff based in Europe as well, in Belgium and Portugal.

This is our last studio day when we got everyone together a couple of months ago.

Photo of the Studio 24 team outside the office in Cambridge.
We work with quite a few different types of companies. A quite broad set over the years we’ve been running. But over the last 5 or 6 years its stuff like public sector, government sites, and not for profit organisations as well.

And the topic of this talk is we started working with W3C in 2020.

We work with UK Parliament, Departemnt of Health and Social Care, CBM, HS2, Crossrail, Crown Commerical Service, Cambridge University Botanic Garden.

W3C logo is added to the list.

So, just to touch on what I’m talking about today.What am I talking about today?
Essentially, today I’m talking about redesigning w3.org which is the W3C website.Redesigning w3.org
And how it changed us as an agency.Redesigning W3.org and how it changed us as an agency
The talk’s in 3 sections. I’m going to touch first on how we worked with W3C and our experience of that and how things are different from the average client we work with.

A few of the project challenges we encountered and what we did about them.

And then what we learned by the end of the process.

• Working with W3C
• Project challenges
• What did we learn?
So, working with W3C.Working with W3C
The first thing of course is that I’ve been saying this word W3C quite a lot and I don’t know how many of you are aware who W3C is. I know it was touched on in Sam’s talk just now. But before today, can you stick your hand up if you knew who W3C was or is. Cool, a few, which is good.

W3C stands for World Wide Web Consortium. They’re a standards body, an industry body within the web. A really important one, it’s been around for over 30 years.

They were founded in 1994 by Tim Berners-Lee, the guy who basically invented the web and what we use today.

They create standards that the entire web is built on. Things like HTML and CSS. Essentially, they help to define what the web platform is that we build all this exciting stuff on top of.

So obviously quite a big deal for us, having worked on the web for 20 years. A really interesting client to be working with.

Who are W3C
They define themselves like this on their website. We develop standards and guidelines to help everyone build a web.W3C logo. “We develop standards and guidelines to help everyone build a web…”
Based on the principles of accessibility, which means the web is available for everyone. Internationalisation so everyone can understand it. And privacy and security so you can trust it. Which is obviously the topic of the last talk.

These all come together into their ethos of creating a web for all. Which essentially underpins all the work they do at W3C.

W3C logo. “…based on the principles of accessibility, internationalisation, privacy and security.”

Creating a web for all.

Back in November 2019, I spotted this tweet. They’d just put a public announcement out looking for help redesigning their website.

It didn’t take me long to realise that would be quite an interesting thing to pitch for. I didn’t have much expectation we would win it at the time of course.

About 32 agencies responded from across the world. Some tiny little agencies, we’re a fairly small one, I guess, really. We’d call ourselves a mid-sized agency, about 17 people.

And lots of big ones as well. Some quite well-respected names in the industry. We went through this process where they interviewed us, and we chatted, and then they shortlisted down to about 3 agencies. And then we managed to win the thing which we announced in Feb 2020.

Screenshot of two tweets from the W3C account
Oct 17, 2019. We’ll want to redesign a subset of our most “corporate” public pages within the next 14 months, while setting ourselves up for overhauling more parts of the site incrementally.Nov 7, 2019. Attention fellow web designers! The W3C Website redesign phase 1 RFP is out: w3.org/blog/news/arch… RTs appreciated
One question some people as is why didn’t they just do it themselves? They obviously know HTML and CSS since they write the specs for them. So, they must have experts who are able to build websites.Why didn’t they just do it themselves?
Well, W3C is a mix of lots of experts, staff, and volunteers, who all work for creating these standards.

There are lots of experts in very specialised fields. We talked to quite a few of them who are like really expert in certain areas.

Experts at what they do
Things like accessibility, internationalisation, CSS. The privacy sand box stuff which was mentioned in the last talk is one of the things also that W3C is involved in.

But a web project needs to bring all these different things together into one cohesive whole. To create a website that works for the users and obviously the organisation.

We have specialisms that W3C doesn’t have. Things like user experience design, information architecture, being able to help advise on how content should be organised. These are things they weren’t so strong on within W3C.

Accessibility, Internationalisation, CSS, etc.

A web project has to bring all this together.

And also, like lots of big organisations, they are very busy all the time. And the core people we work with, there’s not huge numbers of them either. There’s lots of projects and lots of demands all the time.

So obviously, like most clients it makes lots of sense to outsource this stuff.

Like most big organisations they are busy with lots of projects.
I wasn’t very aware of how W3C worked before we actually worked with them. I was aware of what they did. And I keep in touch with lots of the standards.

Coralie Mercier, who’s the head of communications at W3C, she’s one of our key clients on the project. She published this blog post not so long ago explaining how W3C works.

On the left you’ve got 52 working groups which are split into lots of different, um, volunteers, members and invited experts who all work to create these standards and work on them.

So, it could be big companies like Google and lots of experts in the field obviously.

Something like 15,000 people are involved in creating the standards for W3C, so it’s a huge number of people.

On the top right you’ve got the actual core staff who are employed by W3C. So quite a small number in comparison to the rest of them. And they obviously work to create these standards which I’m going to touch on today.

Infographic from Coralie Mercier at W3C showing the day-to-day work of W3C to produce web standards “leading the web to its full potential” including the role of public, working groups, W3C members, and staff.
The actual W3C team is split into a number of different groups.

People, you know, deciding what kind of strategy W3C should be working on, supporting the members. I mean, almost all of their funding comes from paid members, so that’s really essential for them to carry on their work. And people support the standards process and help that to move along smoothly.

And then you get a few people who are more involved with w3 itself and the operations side.

We ended up working just with 2 sections really. The communications team, which is headed up by Coralie as I mentioned earlier. And the systems team who are essentially the IT and the developers. And they’re the ones that maintain the w3.org websites and all the infrastructure that sits on.

And they’re a fairly small team. It was 4 or 5 people were involved in the core team who we worked with. Although there’s lots of other people that we chatted to within W3C.

Infographic from Coralie Mercier at W3C titled The W3C team.

In the centre is a group of stick people including one labelled CEO. Around this group are clouds containing support, strategy, architecture & technology, industry, project.

So, how did we end up working together, how did it differ from normal clients?How did we work together?
The first obvious thing to note is that the project started in March 2020. And obviously something very big happened in the world.March 2020
Back when we started we were based in an office in Cambridge. And, we had flexible working so people occasionally worked at home. But most of the time everyone was together.

And this is our whiteboard wall which we had on the side of one of our rooms, where the team got together, wrote lots of ideas down, things to ask the client, project risks, this kind of stuff.

And that lasted about a week until we had to close the office. We were never to return to that office. I think it’s been knocked down now and there’s a bunch of flats there instead.

Picture of a whiteboard from the studio 24 office, with 5 columns of notes.
Very quickly we turned to doing what everyone else did of course, which was working online and finding our way in this new remote-first way of working.

This is one of our team meetings back from May 2020.

Screenshot of a video call with the Studio 24 staff.
So, adapting to full remote was difficult. Obviously, there’s a pandemic going on as well. So, we had to support the staff quite a lot, give them flexibility, you know, some people needed time off for various different reasons.

And as the owner of a business, it took me a while to work out the best way to support the team. So, time was really disrupted in the first month or two of the W3C project.

We had a few team members chatting to them but quite a few of us weren’t able to be involved. Which made it a tough start.

Adapting to remote first
W3C is a distributed organisation. They’ve been doing this for decades, so it was really helpful to work with them. Coralie, she wrote some remote working standards, which are probably public on the web I’m sure, back in 2005.

I think recently they published some standards on how to make remote meetings more accessible as well, which is really interesting.

So, they ran really effective meetings, they read stuff in advance – which most of our clients often don’t do. You know, asking useful questions and sharing useful notes afterwards. They had a bunch of ways of working that was really helpful. So, in some ways they were the perfect client to work with in a pandemic.

We ended up talking to people all over the world. The core team are based down in France at a research campus called Ersin. But there are people in Canada, Japan, US, all over really. Apart from, having to line up time zones occasionally online meetings worked really well.

W3C is an international, distributed organisation.
So, one thing that’s different to most of our clients is that W3C operate with this consensus-based decision-making model. So generally, in their work, they try and get as many people as possible to input on decisions, um, before they make them.

So, this is essentially how the standards process works. But they applied it to some of the big decisions we had to make in the project.

Small stuff, you know, day-to-day stuff, obviously the core team were able to just decide on, so that things ran fairly smoothly there.

But quite a few big decisions W3C was really keen to involve quite a large amount of people and the rest of the community. Which is different for us – we’re not really used to that way of working as an agency.

Some of these things are things that agencies would just decide themselves while building stuff. But, as I said, we had to adapt to how they worked.

Consensus-based decision making
One example of this is deciding how we build the front end – essentially the HTML and CSS. So, this was mostly around the CSS approach. Which, for those who aren’t aware it’s essentially how you do the design and layout of web pages.

Given W3C publish standards on CSS, they wanted to be seen to be using best practices. And they want people to be able to learn from the kind of stuff we do.

And yeh, that kind of thing isn’t usually what you talk about with clients. Usually agencies have their own way of doing things. Or you might be constrained by the tools you use.

CSS approach for W3C
So basically, we had two choices: Bootstrap or our own CSS approach. We’ve been working on this thing, Apollo, that’s what the team calls it. It was created a couple of years before working with W3C. It’s just a set of patterns and components that help us build out good-quality accessible websites.

Bootstrap, however, was something that the systems team were familiar with. It’s obviously really well supported in the industry, lots of documentation, loads of people know how to use it and it’s got lots of stuff in it as well.

We wanted to avoid things like, I mean we worked with some of these framework systems before, like Foundation, quite a few years ago now. We found we had various problems with flexibility, not quite being able to implement what we wanted to in these things.

We also wanted to avoid bloat and make sure things were performant and fast. And things like accessibility were really important to us as well. We wanted to be able to control that.

And as I mentioned, W3C wanted to be seen to be using the latest front-end technologies as well, not just being constrained by whatever the old version of Bootstrap you might be stuck on is doing.

B / Apollo
Bootstrap vs our own CSS
So that process, we first had to write, um, publish our thoughts on this working in the open site – about what we thought the pros and cons of the two different approaches were.

This is the article that was written by Nicki, our front-end lead developer. I’ll talk a bit more about the working in the open stuff in a bit.

Screenshot of the W3C / Studio 24 working in the open website with a post about choosing a front end framework.
And then we had a big call with lots of people – something like 30 or 40 people I think it was. So us and the core team at W3C, a bunch of people on the advisory board, which is essentially the management of W3C effectively. And they invited experts who kind of came in as well. We even had a guy called Bert Boss who is basically one of the founders of CSS, he essentially created it, with others as well.

So, when we went into that call it was a little bit intimidating. And things like imposter syndrome raised its ugly head a tiny bit.

Big scary team call with W3C experts!
But it turned out they’re a really nice bunch of people. And once we started talking shop it became a lot easier. We learned just to have confidence in your expertise and just be open and have a positive attitude when meeting lots of people. Chances are everyone is wanting the best result at the end of the day.Heroes are people too
So, we ended up choosing our own custom approach. I think W3C preferred the fact that we could keep it leaner, the CSS, and make sure that accessibility is really focussed on.

So, we essentially created some projects which ended up being open source. So, Apollo was what it was originally called as I mentioned. And this became the basis for the HTML and CSS for the W3C site.

And it’s not exactly a design system at this stage, it’s just really patterns and components and ways of building HTML and CSS.

Screenshot from GitHub: Apollo by Studio 24.
That kind of evolved after we finished the W3C project, which we’d done lots of work in and there was lots of accessibility testing. This kind of evolved and the team decided to rename it to Amplify because it had changed so much.

It’s essentially the same thing just a lot better than it used to be. And it has a bunch of really well-tested accessibility components as well, which is really helpful.

And that’s what we now use for all of our client work. So, it’s helped us a lot as a business. And as we iterate this, hopefully some of that stuff can work back into the W3C site.

Screenshot from GitHub: Amplify, welcome to the Studio 24 starter kit for design and front-end development.
So, working in the open. I don’t know how many of you are familiar with this term? But it essentially means when you’re working on a project, sharing your work publicly as you move forward. Has anyone actually, raise your hands, has anyone worked in the open on any projects? No.

So, it’s not something we’re used to as an agency. W3C, it’s how they work all the time. So, everything that they do is essentially published as they go along, down to even meeting notes a lot of the time. Which makes sense for obviously developing standards that have to be accepted by the web.

Working in the open
For us as an agency, we had to get used to that way of working. We tried things like, obviously the code was public – that’s a fairly easy to-do, so public GitHub repos where most of this code is based.

We had a working in the open website where we published the work as we went along. Things like documents, design ideas, prototypes, build templates.

W3C also tried to gain feedback from the community throughout the process. They shared stuff on their blogs and twitter and places like this.

Most of the stuff we shared we had some review process first. We didn’t share everything we did as we went along. We felt that was necessary for us to check what we were doing before we published it. We wanted it to feel like it was right rather than quick and dirty.

We tried:

  • Public GitHub repos
  • Working in the open website
  • Occasional week notes
  • Share work after internal and client review
This is the working in the open website, which we published between April 2020 and April 2022.Screenshot of the working in the open website: W3C website redesign project
But it was quite difficult. I mean, we’d taken the decision to do this working in the open stuff in our time and not charging it to W3C.

But it took a lot of time to do. And even things like writing week notes took quite a bit of time.

There was perceived pressure from the community. We felt like we needed to make sure what we published was right, rather than, as I say, publishing rough and dirty stuff.

In reality, there wasn’t a huge amount of critical stuff from the community, which was good. And maybe, on reflection, we should of just published more draft stuff as we went along. But we also, obviously, had other projects we were working on at the agency. So, balancing this work against that was tricky at times. It wasn’t the only way we work, the only way we do things.

There was also responding to the community. Sometimes things popped up on Twitter and other places. And some of the team felt some pressure and didn’t particularly want to reply publicly about some of this stuff. So as the leader of Studio 24 I just decided to do that stuff instead and leave the team free to get on with other work which seemed to work fairly well.

This was hard:

  • Regular week notes
  • Finding time alongside normal work
  • Pressure of community scrutiny
  • Responding to the community
Our front-end team lead I mentioned, Nicki, worked on most of the Amplify / CSS code. She wrote this nice blog post at the end of the project about her experiences which was really interesting. There’s a link on our website there.

And she kind of framed her role by the end of curating all these front-end best practices and bringing them together on to the W3C site. And hoping that might share it with a wider audience because of who they are. Which I thought was a nice, positive take away for her to have at the end of the project.

A quote from a Studio 24 blog post: “I reframed my role as a curator of front-end best practices, collating the valuable work of my peers and hopefully bringing it to a wider audience thanks to the reach of W3C.”
So, I’ll just talk now about three challenges we had on the project.Project challenges
The first one was the scope.Illustration of a woman pushing a wheelbarrow of web content e.g. map markers, @ signs, play buttons.

Text: #1. Project scope

There was a lot to consider in the project. I mean W3C has been around for, I mean the website itself has had stuff added to it for over 30 years. It’s not one website, it’s 100s all kind of patched together using different systems to run them.

And the core website as it stands is kind of a patchwork of various different things.

And there’s lots of content, something like 2 million web pages or so. And so there was a hell of a lot of technical stuff that we had to review.

A lot to consider
This is just a touch of some of the things we looked at in the planning phases.

Some of these things agencies would just decide what you’re doing, like an agency might have a CMS you just use. But that wasn’t really the case on this project. And quite a lot of these things we had to go into a fair bit of depth.

And there’s stuff on the working in the open site about most of these things.

  • Organisation goals
  • User research
  • Design direction
  • CMS strategy
  • Stakeholder interviews
  • Tech systems audit
  • CSS approach
  • URL strategy
  • Content audit
  • Performance audit
  • CMS platform selection
  • Headless CMS
  • Hosting architecture
  • Security requirements
And the quality bar for the project was really high. And that was partly us because we knew who we were working with. You know, W3C is important to us and we want to do a good job obviously.

And partly W3C, you know they interrogated quite a lot. You know, we had to talk to lots of people at lots of stages in the project.

The quality bar was really high
And it felt a bit like we had to justify all of our decisions quite a lot of the time. A lot more than the average client. Which obviously took a lot longer time to work on.We had to justify all our decisions
And W3C wanted to involve the community as well. It wasn’t just about them getting what they wanted. They didn’t want to just dump a website out onto the world without consulting with anyone. They wanted to give opportunity for people to actually feedback.W3C wanted to involve the community
In the end this was mostly people involved in W3C already. We didn’t get huge amounts of external feedback from people who were not connected to W3C at all. It would be nice to see more of that.

Once the beta site is fully launched, which is currently being finished off by the W3C team, chances are we’ll probably get a lot more feedback. I guess people are busy. They often don’t have time to respond to things when you see bits and bobs of progress.

But, you know, W3C did try to engage the community, which is good.

This was mostly people involved in W3C already
The project took a lot longer than we thought.

We thought it would be just over a year or so maybe, but it ended up being 2 years we were involved in most of the work.

A lot of that was ‘cos of the in-depth nature of a lot of the stuff we had to look at. In that first phase when we started reviewing all these different areas of the project you go down rabbit holes sometimes. And end up with lots of work investigating these things.

Some of it was the volume of work. There’s a lot of things to cover.

We supported W3C by extending the project, but we had to stop at some point which is what we did around April / May time earlier this year.

And we’re still keeping in touch with them as they finish bits off.

It took longer than we thought
We worked together with W3C as well. Their systems team, as I mentioned, have a bunch of developers. They know Symfony really well, which is their chosen web framework.

They helped build some of that with us, which was really helpful. It was a good use of splitting up the time we had available on the project. They helped build out parts of the Symfony front end website effectively.

It had a Headless CMS model, the website, integrating the templates we built for them. And that worked really well actually. That was a really good experience. It’s not something we often do with clients, but when we get the opportunity to work with internal teams it’s really nice.

And it also helps things like knowledge transfer ‘cos they need to maintain this stuff in the future and the easiest way to do that is to actually work on stuff.

Worked together with W3C team on development
So, in the latter half of the project we prioritised a lot more heavily what we worked on. That was, obviously, a good way to work out what you need to be doing.

We made sure that what we worked on was the stuff most valuable to W3C, and tried to get their team to work on other parts of it.

We didn’t use an agile approach on the project which, potentially on reflection, could have been useful. I don’t know how many people use agile stuff in your web agencies as well? But it can be difficult to work on big redesign projects where you’ve got a big deliverable at the end of it and you can’t just deliver part of it necessarily.

But it’s something I’d like to explore more in the future.

Prioritised what we worked on
Accessibility is obviously really important to W3C. They publish the standards and guidelines on these things. And it’s something we’ve cared for as an agency, ever since I started.Illustration: an American footballer kicking a ball through the goal. The ball says W3C. Standards is written in the grass by the goal.

Text: #2. Accessibility really matters.

You might be aware accessibility guidelines have different levels you can conform to. Like A, AA, AAA.

A is like very basic conformance, AA is usually seen as the standard that most people go for. It’s what most of the legislation around the world is based on. In the UK, public sector websites have to be AA compliant.

And AAA is just an extra level. So, things like if you’re thinking about colour contrast to make text really readable against coloured backgrounds, AAA is just a bigger contrast to make it really easy for people.

So, we used the same approach we use on most websites. We made sure definitely everything was AA compliant, but then we tried to make as much as possible AAA. Because if we can’t do it for people like W3C, who really has a chance of doing it at all?

With accessibility it’s also important, depending on who your users are, would probably inform the kind of accessibility levels that you go for as well. But we needed to try and keep this as broad as possible for W3C.

And we managed to make quite a few components AAA accessible. Things like the navigation, which is obviously quite a critical bit of the website.

If W3C cannot meet AAA, who can?
We had help as well, which is nice, from a few W3C experts – something else that doesn’t tend to happen on client projects.

People Like Leonie Watson and Hidde de Vries who are both accessibility experts in their field and involved quite heavily in W3C.

They helped with things like, give us some guidance on how to do various bits of accessibility for front end components and help test bits of it as well which was really helpful.

We had some help from W3C experts

Head shot of Leonie Watson and Hidde de vries

But as an organisation, W3C doesn’t have the time to do things like accessibility audits, that’s not what they do. They write the specs you can do audits against, but the team’s too small to do that kind of work.

So we worked with an external agency. We worked with Digital Accessibility Centre, based in the UK. There are loads of these kind of testing companies out there. But if you want to audit your website or web product for accessibility, you need to work with specialist partners like this. And they’re really helpful, especially if you engage with them early.

W3C don’t have the resources to do accessibility audits

DAC logo

And that’s one of the things I talk to people about when talking about accessibility. It’s really important to consider it from the start of projects and not treat it as some kind of add-on phase at the end – which is what often happens on projects on the web.

If you do accessibility at the end, it’s really difficult to retrofit certain things. If you’ve got custom components in React or something complicated… user interfaces. Baking in accessibility is a lot easier if you consider that stuff from the start.

Think about accessibility at the start
It informed lots of things in the project such as the HTML CSS approach I mentioned earlier.HTML / CSS approach
And one of the other things is the CMS platform choice. We considered accessibility quite strongly in that.

And when I talk about accessibility in a CMS, Janus mentioned a little bit about this at the start. It’s not just about the front end, which we were very confident we could make accessible and that was what we were getting audited by DAC.

But it was the actual CMS editor itself, the actual back end effectively. And that’s a lot more challenging to make accessible because they are usually really complex user interfaces.

So we basically did some CMS platform research as part of the project. Again, all of which is published on the working in the open site.

And we were looking at the PHP stack primarily because that’s essentially what the systems team is used to and what we knew they’d have to maintain in the future. That’s our specialism as well. So, we reviewed a bunch of popular CMSs and tried to work out what would be best for the project.

CMS platform choice
And we ended up with Craft CMS. I don’t know if anyone’s ever used this or heard of it? But it’s a great CMS, really good for structured content, good for developers, has a GraphQL API so it makes it quite easy to integrate.

But the important thing for us wasn’t just the features it had, it was actually that they baked-in accessibility into their process and workflow. Which is quite unusual, we find, when talking to CMS vendors.

They use accessibility as a check whenever they’re looking at new features. They hired an accessibility lead engineer. And that was during the W3C project which was really interesting. And they still have one of them which is fantastic.

So, if any of you work, or are CMS vendors, having someone who leads on accessibility, or if you’re creating products for the web, it’s a really positive step forward.

And they publish stuff on the web, so this is their accessibility section on their website and they post various updates. They, at the time, strived to try and make the editing system fully accessible by Craft version 4. They weren’t able to do all of that, but they were quite transparent and they did an audit which they published on the web so you can see exactly where they’re lacking in what they’re trying to improve on, which is really good.

And we had direct access to their team as well, which made it really nice and really easy to get help on the project as we moved forward.

Screenshot from the Craft CMS website.
Accessibility: tips, tutorials and updates on accessibility improvements coming to Craft CMS.
Another thing we did that helped with accessibility was creating a design system for them. Obviously, part of the work was creating a new look and feel for the W3C website.Bring consistency with a design system
And we ended up publishing that as a design system which is available on the web.

It’s essentially like a bunch of patterns and components which we built the W3C website with. But the intention is that they can use this to build other websites as well.

As I mentioned, w3.org is made up of hundreds of different websites it’s not just one. And there are loads of different groups: these 52 or so working groups that are involved in the standards process, there’s loads of community groups that exist as well. And many of them create their own stuff which is published on w3.org.

And at the moment it’s a mish-mash of various different styles. The hope is in the future people will be able to use the design system to help build other web products within w3.org.

And because we knew the systems team was going to have to integrate a lot of this stuff, this helped us document how to do that. And made it easier for them to implement this stuff on the web.

So, as well as having some consistency of design and making sure things look the right way for the website, it’s helping the people actually build the stuff as well, which is important to us.

That’s why the design system isn’t just the templates and the code. There’s documentation as well and things like accessibility considerations which we documented throughout the system.

Screenshot from the W3C design system.
Navigation: the following example shows how the global navigation sits within the header component.
Some stuff was quite hard to build, though. Navigation is a good example of that. It’s often quite a complex part of a website. And we went through a bunch of different testing on that and quite a few iterations. We wanted to get that right and make sure it was fully accessible. Because that would be awful if we built a navigation system and certain people couldn’t use it.Some components were hard
We went through about 4 iterations as I mentioned. We had a bunch of people, some accessibility users as well who helped us test that which was really helpful.

We had things like this close button on the top right which we thought might be useful for non-sighted users, it turned out it wasn’t. And there are other easier ways to open / close stuff within HTML.

Some of the changes were mostly under the hood so didn’t necessarily look particularly pretty at this stage.

We were testing the accessibility side of it and how all those interactions worked. And then we layered UX on top of that step-by-step.

Until we get a bit closer to what we ended up with. Which is basically this. And obviously this looks a bit different on mobile, it compacts down to a simpler menu.

One of the techniques we used when testing this – we just created static HTML prototypes, so it was really easy to get that stuff updated, get it into a browser, and just ask some users to test it.

This stuff was public on the working in the open site as well so other people were able to look at it if they wanted to.

Having static prototypes is a really nice, fast way to do things we find. Rather than trying to build something into a CMS can obviously slow you down hugely. So, keeping stuff simple is good.

3 screenshots from the W3C design system, showing the iteration of the design.

Page copy:

  • Standards:
  • About W3C standards
  • Technical reports
  • Translations of technical reports
  • Types of report we publish
  • More about standards.
Internationalisation, which is a bit of a mouth full. But it’s an important part of W3C, it’s one of their key principles. And their current website is primarily English and they’ve got individual pages sometimes translated.

They currently have a couple of sites that are maintained by separate people in Chinese and Japanese. But one of the ideas was to try and bring that stuff together. And allow the Japan and China teams to manage content in Craft and then create it within the framework of the new W3C site.

There are 3 core languages for w3.org: English, Chinese, and Japanese. But they’ve got something like 25 other languages that they publish content in. That’s things like press releases that obviously go out worldwide, sometimes blogs and news content. And that includes right-to-left languages like Arabic as well which we had to make sure our design system worked properly with.

Illustration: illustration of a person wearing a black t-shirt with W3C on it. They have a tin can to their ear with all kinds of letters in various languages along the string.

Text: #3. Internationalisation

We find as an agency, when clients come to us saying they want translated websites it’s important to work out what you mean by that first. ‘Cos in most of our experience people have completely different requirements.It’s important to work out what you mean by internationalisation
For W3C it seemed to be most of those requirements rolled into one! So, the traditional thing, having these separate websites in different languages, the localised websites, was required for the Japan and China sites. But they also had translated pages within the English site that had to sit there alongside other stuff.

But when we built them you didn’t want the middle of the page in Arabic and the header and footer in English as that would be really weird, especially as that’s right to left as well. It would be a very confusing user experience.

So, we had to have these embedded pages which were fully translated and were linked to from the English site. Things like press releases – which is the most common use case at W3C for translated content.

And you also had things like inline localised content, so you might have bits of French in the middle of a page. And again, we needed to make sure that was tagged up in the proper way. There’s ways to do that in HTML, to say that’s in a different language, which then tells browsers that, which then helps users.

What are we translating?

  • Localised websites
  • Translated pages
  • Inline localised content
There’s the user experience side of it as well. So, there’s a guideline within the W3C standards called content negotiation, which is basically around automatically redirecting users to the language that you have a preference set in your web browser for.

We didn’t like that idea and we have multilingual staff within Studio 24. We have Marie who’s from Belgium, she speaks a bunch of different languages and when she goes to websites, she doesn’t want to be automatically redirected to say the French version. She might well want the English one instead.

We felt it was important not to automatically redirect people. It can be confusing as well sometimes. But we just opted to have really clear links, so you can see very obviously that there’s a Japanese website and you can visit it.

Or if there’s a press release, there are really clear links near the top of the page to all the different languages.
So, we think it’s better to let users choose that kind of thing.

User experience

  • Don’t automatically redirect
  • Clear links to translated content
  • Unique URLs for each language
There’s the CMS management side of things which can be quite complex sometimes. Especially in CMSs that don’t natively support different languages. That can be really problematic, often.

I mean, there are some CMSs that have plugins to enable that kind of thing, but we tend to find they’re not massively reliable.

Craft did have native support for internationalisation, which made it a bit easier. And it kind of managed it by separate websites effectively. Even though they’re not literally separate websites all of the time.

CMS management

  • Native support for internationalisation
  • Separate sites in Craft CMS
  • Supports independent pages
And this is what they look like. This is an English page, one of the press releases actually, which as I said, is one of the things they publish most frequently in different languages.

Currently the press releases are literally static HTML, they’re not managed by anything at all.

And then clear links to different languages as you can see just up here. And importantly using the actual native language to provide the link rather than saying it in English which wouldn’t be particularly helpful to anyone.

Screenshot from the press release page on the W3C website.

Headline: World Wide Web Consortium (W3C) launches internationalization initiative.

Links to read the press release in Arabic, French, Dutch, Chinese and Japanese.

And there’s the French version. Notice there are bits of English text dotted around, that’s because they’re text within the template that hasn’t been translated yet. But this is coming from the beta site that’s still in progress.Screenshot of the same press release in French
And then the Arabic version of one of the press releases. So, everything switches right to left.

In an early version of this, because this isn’t a separate website and it’s a translated page within the English site, when we first did it we had an English header and English footer. Which meant that the English stuff was on the left and in English and then everything was on the right. And then again everything swapped at the bottom of the page. Which, as I say, was a very confusing user experience. So, we switched to do everything translated which made a lot more sense.

We had some help as well from another W3C expert Richard Ishida, who’s head of their internationalisation side. And that was really useful just to guide us and help tweak things as we move forward.

Screenshot of the same press release in Arabic.
So, three challenges, just to sum up, we encountered on that project. These kind of things obviously affect most of our projects quite a lot of the time. But they are particularly complex for W3C.Challenges

  • Project scope
  • Accessibility
  • Internationalisation
So, at the end of what was quite a big project for us, what did we learn?What did we learn?
First, we learned it’s really important to adapt to how large organisations work.

Once we got into the swing of working in a way that worked with W3C, things became a lot easier.

And as I said earlier, they are so used to remote working that really helped our working practices as we were adjusting to being remote first. Which, in practice, is what we are today still.

Adapt to working with big organisations
Good communication is really critical. Well, it is with any client. But it’s really important when working with a large organisation like this.

For two years we met them every week for status update meetings. And when we worked with the systems team we became a bit of an integrated team which was lovely.

We had daily stand-ups, we used a shared Jira board – and that really worked really effectively.

We also used Slack with W3C which is not something we usually do with clients. So, we use the Basecamp project management tool which we find quite effective to centralise communication. But Slack’s quite a nice way to immediately chat with people. And they’re used to this kind of stuff. I mean, W3C use IRC quite a lot, for example, and they’re starting to use Slack more and more.

So yeah, that’s the first client we’ve tried that with and so far it’s been a good experience.

Good communication is critical
As we progressed through the project we learned focusing on what brings the most value is really important. I think we went down the route of looking at too much, initially. And it got bigger and bigger as you started talking to more people and realising how big some of these problems were to look at.

But we realised that you have to then focus in on what we can do well and then leave W3C’s team to do other parts of it.

Focusing on what brings the most value is an agile principle again. So it’s something I’d quite like to do more of in the agency and find ways to make that work. As I said, I think it’s quite challenging for agencies to do that often. It’s seems to be easier in, like, long-term projects within organisations. But if anyone has experience of that I’d be happy to chat to them later.

Focus on what brings most value
And I think it’s good to take on projects that stretch you. I mean, this obviously seemed like a really big project. So, I think at certain levels of large projects there’s going to be stuff that challenges most teams. I think we realised that as we moved on through the project.

It helped us become more confident as an agency. And more confident to take on similar work as well. And it helped, I think, grow the team members who were involved in the project. Which is pretty much most of the agency at one point or another.

[Simon laughs]

Stretch beyond your comfort zone
Keeping your team motivated is obviously really important too. I mean, the project spanned 2 years, which is a long time. We do work with clients for a very long period of time like Crossrail, which is the new London Underground Elizabeth Line. We worked with them as their digital partner for 13 years. But that’s more of an iterative process, where you evolve stuff over time.

Working on one project for the best part of 2 years is quite a big ask for people. But taking care of people is really important to me at Studio 24. We put a lot of work into giving people flexibility, supporting them. We have things like mental health practitioners within the agency which is really helpful.

And also, within a pandemic, it obviously affected people in different ways. Not everyone had ideal home environments. We had this horrible thing in the UK where we had to do home-schooling. So, for someone with kids it was incredibly difficult to focus on work and be expected to do that stuff as well. So, we had to be very flexible for that first year or so during the project.

We did a few things differently. We implemented things called governance meetings where the project manager working on a project met with a bunch of management team and we monitored how things were going. Not just with the project and how successful things were going, but also with the team as well and how they felt. So you were able to make changes as you went along.

We gave people flexibility. We set realistic expectations for them. We didn’t try to hammer them to get stuff done really quickly or anything like this. So we gave them the freedom to do good work which really helped in the end.

Keep your team motivated
Working in the open is hard. I think we found that a relatively tough experience. But it’s something that’s really valuable and I’m glad we did it.

I mean, like today at the conference, it’s good to share knowledge with others. And putting your stuff out there in the open as you work is one really interesting way to do that.

We quite enjoyed engaging with the wider community and occasionally have discussions with other people about aspects of the website.

And it’s good to learn from other people as well, because you can make your own work better.

Working in the open is hard (but worth it)
And it feels good to help W3C move forward. They’re going through a bit of an organisational change at the moment. Even though they’ve been going for 30 years or so, they don’t really have a formal legal structure.

They’ve been associated with these host organisations – universities like MIT and research organisations like Ersin based down in the south of France. It’s where some of the team, the staff, are based in these places.

But they’re turning into a not-for-profit at the moment, which is supposed to happen next year. So it’s good to help W3C move forward, we hope, as they transform into this new organisation. The new website helps them along that journey.

And it’s helped us as well, transform as an agency.

It feels good to help W3C move forward
So, this is the existing website if anyone’s ever seen it? Quite busy, lots of text.Screenshot of the existing W3C website homepage
And the new website looks like this effectively. This is a snapshot of the current beta website.Screenshot of the new W3C website homepage
And on mobile, it’s, kind of, even more crunched text and difficult to read, especially if it’s things like news articles or blog posts you’re looking at.

But as you can see the beta site has this banner at the top. The intention is to get active feedback from people as we move forward. I mean there is a GitHub repo that is accepting any feedback from people on this at the moment. I think that’s where the feedback thing links to.

Two screenshots next to each other showing the mobile view of the existing W3C website and the new W3C website.
And three days ago before web summer camp, before coming here, I took the opportunity to go and visit them for the very first time. It’s down in Sophia Antipolis which is in the south of France near Nice.

That’s Coralie, Jean-Gui one of the developers in the systems team and Vivian who is head of the systems team.

And it’s funny, because working with a client for 2 years and this is the first time we met them which is really nice.

The beta website is being finished off by W3C at the moment. They’re finishing some data migration, which ended up being way more complex than they thought it would be. Probably because they’ve got 20-odd years of stuff that’s been added to and things like different user systems.

And some content writing and once that’s finished we’re hoping the thing will be launched. Hopefully by the end of the year. So fingers crossed!

Selfie of Simon with Coralie, Jean-Gui and Vivian. They are outside in the sunshine with trees and blue sky in the background.
Thank you very much


Twitter @simonrjones
Janus Boye: Alright, comments, questions, reflections? I really enjoy these case studies and hearing about the real-world problems that go out of there. And I think it’s also really interesting to hear about projects that are out in the open, which is not usual. But thank you for sharing, Simon. And also so openly with us. So let’s hear from the first here.

Audience member: could you tell me, you said you adapted to the client processes and everything. Did they change anything from their side to adapt to you maybe? Or learn something from you that they can use in their processes. That’s one. And translations are all done manually, you weren’t using any integration with some translation platform or something like that? Are the translations already done?

Simon: I’ll touch on the second one first. The translations are all manually written as far as I’m aware. They’ve been doing this for a long time. So, I think they have teams across the world to help with that. I don’t believe there’s any automated translation at all involved in that.

I mean, the Japan and China team are in Japan and China, so they write the website themselves, that’s the intention. But some of our clients use those kinds of tools, especially to speed things up at the very least.

And did W3C learn anything from us? I’m sure they did [laughs]. It’s a really good question. I think, so, they’re not very experienced with web [redesign] projects which is something I didn’t realise when first working with them. The last time they redesigned w3.org I believe was 2008, so it was a long time ago, 14 years or so.

So, I think throughout the project they’ve learnt things like prioritising stuff and trying to focus on what gives most value. You know, future projects we might work on with them will be a lot more focused I think. I think when we started working with them they had the attitude of we want all these things and we need to look at everything and I think they’ve revised that a little bit is my perception. So, thank you.

Janus Boye: alright, another question

Audience member: First question, so, how challenging was it for you to define personas taking into consideration technical expectations both from the client and the community? And also taking the accessibility part.

Simon: Was that personas did you say?

Audience member: yeh

Simon: Um, god that was so long ago [laughs]. That was a really, really early part of the project. I think that was the very first thing we did. And Ian Axton, our creative director, worked on that. I think it was one of the first posts on the working in the open site. As I recall it, you know, I can’t remember exactly how challenging it was if I’m being honest.

But I do remember some parts of the project we looked at in a bit more detail. Like the technical reports page, the TR page. If you go to w3.org/TR that’s where they publish everything. So that’s where the standards for accessibility and CSS and other things are all published. It’s a fairly dense page, it’s difficult to understand. And when we redesigned that we were thinking quite carefully that we wanted new people to be able to understand that. And lay people just to be able to go there and go I want to see something about accessibility and I can find it.

But also, we acknowledged that it’s used by experts. So there was a bunch of quite specific requirements they had. Like they wanted everything to be on the page at once, for example. No pagination because that’s how they were used to using it.

We ended up talking to experts who use the TR page a lot as well as trying to think of it from the perspective of new users which was challenging. That took quite a while. We ended up iterating that one as well about 3 or 4 times. I didn’t touch on that in the presentation, but it’s on the working in the open site if you want to read more. But it was challenging, but interesting to work on.

Janus Boye: alright, anybody else? Do we have one more? There’s a question over there perhaps from the crew?

Audience member: the talk was really great and you mentioned that everything was open source and I guess that peer pressure from the community was really great, really high, even mentally for you. But do you accept pull requests or only comments on your code?

Simon: Well, we, I’m happy to accept pull requests on the stuff we do. We made things like Amplify open source because it works for us.

We work with a bunch of public sector clients in the UK and they like to use open source stuff. And it’s also easier for us for licensing, we don’t have to worry about the client taking copyright of the website ‘cos we know that we own the bit that’s open source. So that stuff, yeh, there’s pull requests and things like this. I help maintain a WordPress config thing as well, which we accept things like pull requests on.

The main W3C project, that’s all open as well. So technically anyone can go there, log issues, and potentially contribute if they wanted to.

Audience member [inaudible] … pull requests

Simon: well, that’s not up to us at the moment, that’s the systems team basically. So, we might advise them and talk to them about it, but it’s up to W3C what they do, so. Technically I would think they would be open.

Audience member: But in process of development, you did not have any pull requests from the community [inaudible]?

Simon: No, not really. That could have been something we looked at. It’s quite hard to manage that I guess. We kind of, you know, you’re trying to develop a product, a website, and you need to do that and finish it before then looking at stuff. So, I suspect for Amplify that will be easier in the future. But at the end of the day Amplify’s for us as well, so it’s not for everyone.

So, I guess anyone with an open source project you need a purpose don’t you? You need a vision for it. So whatever changes need to fit that vision.

Janus Boye: OK thank you. We have one more question here.

Audience member: You mentioned about the Chinese translation as well. With a platform or website like that, did they have to translate it or were you as an agency responsible about the censorship there, about the regulations in regarding the content? Ah, what had to be published, how certain things had to be translated? Had some content had to be changed just to fit the regulations there? Ah, I could imagine with a platform like that there must have been some challenges, some content that might have had to be changed. How did you deal with that?

Simon: To be honest, we didn’t end up encountering that kind of problem because we weren’t really working with the Chinese team. We built the system, we had some feedback from them as we were building stuff in the early days. But we build the system and the CMS to be able to manage that content. They’re currently working on it as far as I’m aware. So, it’s not something… it’s fairly early days, I think, for the Chinese site.

But, I’m guessing the current Chinese website is hosted in the US still, I’m not 100% sure. But it’s a really interesting question. But most of their stuff is standards-based and hopefully not too controversial. But there’s bound to be stuff they come up against, absolutely.

Janus Boye: alright, I think that’s all we have… ok one more. Bonus question, Simon. And you thought you were off the hook.

[audience laughs]

Audience member: before you were hired how did you stand out from other agencies? And how does one pitch in an organisation like that?

Simon: That’s a good question. Yeh, I mean, we went into it passionately believing that we could do a good job. I mean, as I mentioned before we’ve always cared about accessibility, it’s been part of our DNA for a long time.

We had an accessibility lead in the agency which helped massively because it showed we’re serious about it. So I think we were just honest and tried to get on with them, like relationship building. We’re lucky there was an interview process where we were able to talk to them. I think I remember very early on, emailing and saying can we just chat ‘cos initially they were just asking for a proposal. But they were open to that which is great. So yeh, try and talk to people as much as possible.

Janus Boye: And if you go online you can also find the winning proposal, like you can see all the details.

Simon: yes, it’s all online.

NetGen: it’s all out in the open, pricing the whole shebang.

Simon: Not the pricing [laughs]

Janus Boye: oh, not the pricing!

[Audience laughs]

Janus Boye: but I think they had a budget indication didn’t they?

Simon: they did, yeh. Anyway…

Janus Boye: There was an amount.

Simon: Yeh, and all the other ones as well are open which is quite interesting for us from a research point of view.

Janus Boye: Yeh. Alright, I think that’s all we have for Simon. If you liked that talk as much as I did, please let’s stand up and give him his first standing ovation in Croatia.

Camera turns to the audience of c. 30 people.

Janus Boye offers the microphone to audience members to ask their questions.

Powered by Netgen