How we grew as an agency by redesigning w3.org

[audience laughs]

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

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.

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

W3C logo is added to the list.

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.

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.

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

Creating a web for all.

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.

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.

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.

A web project has to bring all this together.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

• Public GitHub repos
• Working in the open website
• Occasional week notes
• Share work after internal and client review

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.

• Regular week notes
• Finding time alongside normal work
• Pressure of community scrutiny
• Responding to the community

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.

Text: #1. Project scope

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.

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 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.

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.

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.

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.

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.

Text: #2. Accessibility really matters.

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.

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.

Head shot of Leonie Watson and Hidde de vries

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.

DAC logo

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.

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.

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.

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.

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.

Page copy:

• Standards:
• About W3C standards
• Technical reports
• Translations of technical reports
• Types of report we publish
• More about standards.

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.

Text: #3. Internationalisation

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.

• Localised websites
• Translated pages
• Inline localised content

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.

• Don’t automatically redirect
• Clear links to translated content
• Unique URLs for each language

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.

• Native support for internationalisation
• Separate sites in Craft CMS
• Supports independent pages

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.

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

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

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.

• Project scope
• Accessibility
• Internationalisation

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.

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.

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.

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]

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.

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.

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.

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.

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!

[applause]

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.

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