[APPLAUSE] So yeah, I'm Edd Sowden.

I'm a front-end developer working for the Government Digital Service, which is a large group within the cabinet office, which is a ministerial department within Her Majesty's Government.

I'm employed by the government.

I'm a full-time civil servant.

Just under year ago, we launched our new website called gov.uk.

It was built to replace all of the UK government web presences.

All UK gov websites will be under it.

There are two main sections to the site.

There's the system bit and the departmental bit.

System bit is for information like bank holidays, registering births, rules of the road and stuff.

The departmental section is for stuff like corporate publishing.

So it's press releases, annual reports, consultations, and stuff like that.

That's the bit that I worked on, the second bit.

So we replaced hundreds of sites like these, which were all different, all weird, with lots of beautiful sites like these, all powered by one CMS.

Each department has their own content.

They are completely in control of their content.

That's not us at all.

And they change quite radically.

They can change the layout of their home pages and stuff.

So It's quite a big project.

It's around 63,500 documents on the site, just on the government bit at the moment.

We have 400 organizations.

And we also host 235 work location sites.

So that's sites for embassies and stuff around the world.

And so we also have around 850 editors, who are distributed around the world editing this stuff.

So we have people in all of our embassies on the site.

This is what it looks like if you were to take a screen shot of every different template.

So each one has its own bits, its own things, all managed via Sass.

This includes pages like the "People" page for Prime Minister David Cameron will be there, policy pages on Afghanistan, and important documents like the price of wholesale milk, which we publish.

Because government does that.

The whole thing was built responsively, mobile first.

So we did the mobile layouts first.

This is a news article.

Each one has to respond differently.

So of each of those pages we just saw, each one has got its own mobile style sheet as well.

This is the same thing in desktop.

So language structure in the top corner, that's because most of the site can also be translated into 48 different languages.

Right-to-left, that's a whole world of fun.

Believe me, developing sites you can't read is more fun than you expect.

I'll come round to that a bit later.

Just quickly, to our browser support, technically we don't support browsers.

We support users.

So browsers we support may not have stats that most people would think is enough to consider supporting.

But for us, those people are important, like my colleagues who will use IE6.

I have to support them because they are my colleagues.

So yes, we have to check everything is functional in IE6 -- functional.

To help us manage it-- because we have a couple of different teams working on this site.

It's not one team.

We have built something called the govuk_frontend_toolkit.

This came around after we built a large portion of the stuff.

So we started rationalizing stuff and merging stuff that we could share for everything else.

Because while we've done the two big bits at the moment, there's still loads of stuff to do.

So this is to help us make things that look like gov.uk.

It contains things like these.

We've got buttons, cross-browser shims, colours, CSS3, media queries, typography and stuff.

Our colours, just a quick note on this.

We standardized the colours.

I said that we did this after we built everything.

And we did an audit of what were colours being used on the site.

And it's amazing how many different grays you end up with.

Some people really like #999.

Then you get people who like #III.

And then you get your weirdos who like 9c9a9c.

It's like what have they been smoking.

So we standardized.

We have five grays.

We give the semantic names.

They're longer to write for us, but it means that we don't end up with 15, 20-- we actually had 40 different grays.

We have five.

It makes everything a lot more consistent as well.

There's no, "what gray do I use?" Use the one it's named after.

Quickly to media queries.

So I said we support IE and IE6.

So how do we do mobile first while still supporting IE6? And I should note that IE7 and IE8 get the full desktop experience.

So how does that work? We used the ability to post blocks into Sass mixins.

So the whole thing is also completely responsive.

It's not adaptive.

So in the old world, we called that fluid or elastic.

So it doesn't have jump points, as these are the points where different layouts come.

It's all completely flowing.

So we only have two breakpoints, tablet and desktop.

they do us.

Usually it's just a case of using one of them on any given thing just to add layout.

You don't really need much more that we found, most of the time.

Some specific pages will have more advanced stuff.

But for that it's fine.

So then IE gets dealt with-- this is a IE style sheet.

IE style sheet just pulls in our base style sheet.

And that's all it does.

You don't put anything in that file.

That file is-- that's the whole of that file.

That's all it will ever be.

Then we have a mixin that looks like that.

Which says, if it it's IE, print out the content.

Otherwise put it in proper media query blocks.

It's actually a slight simplification of the one we actually use.

Because the one we actually use says, "if IE6, don't give it a desktop styles either.

Because IE6 gets a single mobile column.

Because we decided layout in IE6 was something we didn't want to deal with.

It was an executive decision that I made.

Layout is a hard thing to do, especially when you understand what the box model is doing.

Then it's included in the front end like that.

So each browser gets its own style sheet.

You only ever get one style sheet.

IE doesn't get two style sheets.

It's quite nice.

IE hacks-- the old way of dealing with IE hacks was to put them in a separate file at the end.

But that always gets really messy.

Because you refactor something and you forget everything, especially on a large team like ours when people that wrote the thing are probably not the one refactoring It.

So they lose it.

So to put IE hacks in, you want to make it in line.

So using the block thing, you can do that.

You never lose your hacks.

You never lose the things you're upset about.

You're allowed importance inside an if IE6.

That's the only place you can use them.

They shouldn't be used anywhere else.

They're really simple to implement as well.

It's just, if the version of the IE in the IE Sass file is a version with print out the content.

So right-to-left-- I mentioned that earlier, that we do that.

We implement it exactly the same way.

So it switches the thing.

And right-to-left pages have their own style sheets.

So a right -to-left page will have its style sheet.

And it will get the extra stuff for the right-to-left style sheets.

One of the fun things that we learned when we did this was we did the front end and it looked great.

And everything was flipping around nicely.

And we got a person who knows Arabic in, and we put them in front of the CMS.

And we said, OK can you just pretend you're publishing a news thing.

So she sat down and she wrote her thing out in the editor.

And it was like, looks great.

She hit preview and went, this is gobbledy goop.

And we're like, what do you mean it's gobbledy goop? It looks like Arabic to us.

We hadn't switched the direction in the admin.

We'd only switched right-to-left in the front end.

So without getting real users in, we would have never found that.

Trying to read Arabic is really hard, especially when you don't know it.

But it looks normal if it's not switched.

So impossible to debug without a real person.

Make sure you get real people in to test with.

Because it can look fine to you, but it can be really wrong.

Typography is another thing we really standardized.

We have seven font sizes.

These are our seven font sizes.

They're the only ones you can use.

We can't use anything else.

They get included with mixins like this.

They have, in the mixin, the responsive break point.

So all of our fonts will respond at the same point and go down to the smaller size as one set across the site.

So there's no, oh this bit responded here and this bit responded there.

It's done once.

It's done.

We don't touch it.

You can slightly tweak those to add inline heights for buttons and things.

Because buttons you might over style them slightly.

As Paul mentioned earlier, we've published a service manual.

This is a manual we've written for other government departments who are about to redo all of their services.

So things like road tax and all the other things, those services are going to be built not by us, but by departments.

So we've documented everything we've done.

These are some of the topics that we've written about.

Things like accessibility, things like continuous delivery, continuous deployment, and stuff.

Progressive enhancement one is really-- people kind of said, oh it's easy for you because you're government.

And you've got to do it properly.

But the progressive enhancement one is well worth a read.

It's why you should do it properly.

But we are government.

Everything we've done is on GitHub.

The whole source code for the front end is all on GitHub.

Go at it.

Fork it.

Bend it.

Send pull requests.

The service manual, there is the government section, I worked on is there.

And that's the end of my talky bit.

[APPLAUSE] So do we have any questions? So we're going to do questions.

And just raise your hand if you have a question.

I saw a few come up on Twitter during Ed's presentation.

Sir, yes.

(audience) So first of all, as someone who lives in the UK, I just want to congratulate you on the site.

Because I think it's doing profound good in the UK.

My life's got a lot easier.

So thank you, first of all.

But one of the things I was wondering is, you showed a screen shot of lots of different department sites.

And they will looked-- they conformed to the same kind of design.

So I was just wondering-- and that's one of the great assets at this, I think.

As a user who uses it, I can find my way around.

Were there departments that were a complete pain in the ass and demanded that they were the ones that would be different and they had to stand out? Because that's the kind of thing that clients would do, potentially, for me.

Yes there were.

They were told they weren't allowed to.

It was a difficult decision.

But our mandate said that users had to understand the site they were about to land on.

They shouldn't have to relearn how to use another government site every time they landed on another government site.

So that was what our mandate was when it set out.

They are two departments which have subtly different pages, being the prime minister's website, which is subtly different.

Because he doesn't work like a normal department does.

So there is subtle reasoning for it.

Because his job isn't to lay out policy.

His job is to run the government.

So his one is slightly different.

But other than that they were told, sorry.

We have implemented features for lots of them though.

So things like the MOD have their own features because they have to deal with fatalities abroad and stuff.

So they have a whole section of the stuff which we built specifically for them.

Because they're the only department to have to deal with that.

So they were given some reign into features that we could implement for them.

But no, they were all the same.

(host) Next question.

Sir-- it's coming now.

(audience) So does it mean that all the different websites that you took together, do they look all the same now? So beyond their homepages they look exactly the same.

Beyond the homepage they get no control over how the page looks.

They can control the content, but they cannot control the look of the page.

[APPLAUSE] And one of the reasons for that is the content is the king on the site.

The content is the thing which we're going for.

They shouldn't be going for a glitzy website.

We're government for god's sake.

They should be going for information.

And they should be getting their information quickly.

And they should be getting away again.

So there's no need or reason for them to-- I guess we're in a very special place with that one.

But no, it looks the same for all departments.

Next question.

There's one over there.

(audience) So I was wondering.

You made some real great decisions, design decisions.

So how were these decisions made? Because a lot of us here know we struggle with them, all the politics.

And you work at a politician, like a political organization.

So how did that work? It's quite weird working in such a political establishment such as government.

We have to get political changes through.

But one of the ways it's really worked with us-- the talk earlier about teams and working with designers and things-- we work in a very mufti-disciplinary team.

On my team-- I work directly with everyone else's one or two of each kind of person on my team.

But in my daily standup I have designers.

I have back-end developers.

I have the product manager.

And I have everyone else.

So we're very easily able to make decisions amongst ourselves and relay that back to the powers that be.

Like this is a good decision or this is a bad decision.

And that communication is key.

As a developer, me as a front-end developer, being able to go, IE6 is great but the overhead that it's going to cost us, do we want that or do we want another feature? And for each thing that was like, this thing is going to be really completed.

We know you want a carousel, but that's going to be really complicated.

Is the upkeep of that worth this other feature, which you need to act as a government.

So we were to make those decisions really kind of like talk everything through the whole chain.

Communication was really key there.

(host) Next question.

(audience) How long did it take to completely finish and test the projects on all the websites? GDS' department was launched in-- as a department it was formed in February of last year.

From roll out from the first department to the 24th ministerial department, 24 big government departments, took six months to transition the entire thing.

And that transition involved scraping all of their old sites, porting or choosing to not port content over.

Because we ported over all the content that departments published for the last two years.

So that was all ported over.

And all the people in the departments were trained up.

That took six months from start to end for those 24.

Yeah, it was hell to leather for a lot of that time.

It wasn't easy.

And I wouldn't recommend doing it quite so quickly.

(host) Are you saying from the conception, from the design phase, through to moving all those departments over was six months? I started just over a year ago.

And on my first day, the entirety of the government bit of the website looked nothing like it does at the moment.

(host) Wow.

That entire thing took just over a year and a bit in development, a year and a half in development.

It was very quick.

Moving fast is painful in tech.

I wouldn't do that.

We have accrued quite a lot of tech debt, which we're now able to pay off, while transferring another 300 sites over.

But yeah, it was quick.

(host) Yeah, next question.

I will ask on behalf-- oh, yes, please do.

(audience) Did you get any negative feedback? We got resistance.

Publicly? No, which we're still shocked about.

We think it was because it was just too quick.

That no one's really noticed what it is we've done.

But internally, people were upset internally, obviously.

Because departments had roadmaps, they had plans for their digital-- kind of like what they were going to do for the next years.

And we said, sorry.

I know you've got plans, but we're going to replace everything you've done.

So that's the thing.

So they were a bit upset there.

But externally, no one seems to have noticed.

Which is reassuring in a way, but also scary.

Only positive feedback, really.

Except for the "Daily Mail," one of the UK's more interesting papers.

It compared us to boring.com.

Which, if we're boring.com,

I think we've won.

Because we're a government website.

That was the worst they could come, boring.com.

Really? That's like any other politics.

Don't attack the fact that we've moved all government policy onto one place.

No, we're just boring.com.

Ed, thank you very much.

This was fantastic.

Thank you.

Thank you.

[APPLAUSE] I do my research.

Take it away, Anton.

OK, thanks.

I go one too fast.

But who needs names anyway if you've got Twitter handles.

I'm going to talk about 9292.nl.

It's a real Dutch thing.

We redesigned it about two years ago.

And I'm not a developer myself.

I'm more of a strategist than a designer.

So I hope what I have to tell you is interesting to you.

And the interesting thing about 9292 is that it was all about personality in this project.

So for those of you come from abroad, 9292 does public transport planning in a very neat way, buses, trains, trams, boats, everything.

It used to be a phone number.

It's still a phone number.

They make a lot of money on it.

So you better use the website.

And this was what it looked like when they came to us.

They said, yeah well, the functionality is nice.

We just need to update the design a little bit.

So could you help us? And we said, OK.

And we did this.

But there was a whole world in between of thinking about personality, and the brand, and where you want to go.

So that's the story I want to tell you right now in 10 minutes.

How did we get there? First we thought of what would it be like, ideally, in the future? We did the ideal transport planning.

And we thought, what if in the future it's not about working functionality, but it's relevant for users? At that time, 2011, it was a legal requirement from the Dutch government to have this site online.

What if it was actually liked and loved by users? And they were the only ones doing this, so it was a monopoly.

What if they were more like an independent party? And what if they were not only keeping up but one step ahead in public transport planning? What if it's not only about planning travel beforehand, but being a travel companion? And that they were already very, very complete at the time.

It was very unique that you could plan buses, and trains, and boats, and everything in one go.

But you can be even more complete and include things about pricing, about park and ride, about real time information.

So that's the ideal future.

It's really about the traveler.

And the traveler is not the average white, neat, normal guy.

It's everyone.

So it would be great if in the future this would say, "hey Anton, your train leaves in the 11 minutes.

Plenty of time to get your favorite coffee and make to the platform easily."

--and to provide that service for everyone, not just average people with smart phones, and all the time.

Trains are a mess in Holland when it snows.

--and everywhere, not only on the website.

So we are already thinking, how can we bring their information? How can we make it searchable? Which is no easy thing.

And not only everywhere online, but also offline, would be really nice if you could connect all those locations.

So that's the ideal future.

We did a lot of sketching then to make sure it's all complete.

So we wanted to make this transition from robot functionality-- hello, Anton, take a train, blah blah blah to blah blah to a companion coming with me.

How did we do this? All of which I told you just now.

We wrote that up into a brand story.

And it's a little piece of text, fits to an A4 piece of paper, telling the story in very accessible language.

And we shared that with the team.

We shared it with the copywriters, the designers, the developers, everyone to make sure that you really use everyone's creativity for really bringing this redesigned brand to life.

So the designers got to work making it much clearer, much more colorful, doing a very nice icon set, with both clear and some humor inside there.

So you see the-- I love the running guy in the middle.

And we did a campaign, a launching campaign.

So also the ad agency got very creative with the new brand identity.

And the whole idea was that the new 9292 would be traveling with you, not from a bus stop to a bus stop, but from a location that means something to you to another location.

So I'll translate it to you.

On the left it says, from ice rink to [SPEAKING DUTCH].

It's some kind of food.

In the middle it says, from dating site to first date.

And on the right it says, from going out to sleeping out.

So it also inspired the copywriter.

It's very interesting.

And you see there that the big, white planning box in the middle says, "where do you want to go?" It doesn't say "plan your travel."

It says "where do you want to go?" So that's a really also in the text, in the copy of the site, It's a companion.

You can feel it there too.

And I'll show this site for a little bit.

How am I doing on time? So there is-- here you can plan something.

And there are really ugly banners.

We hate them and tried to get them away.

It's not visible.

OK.

Like this? And what you also see is that we did a lot of work on building with our friends from Q on building this really fast auto suggest to remove all the fields we had in the first version.

So right here it's very hard to read.

Anyway I can't read it from here.

And then we can plan a travel, and so you get the results.

But the planner is there always with you.

You can go back to it.

Plan a new destination.

So you can see also here in the whole behavior of the site, in the whole copy of the site, we try to express the brand.

Go back to PowerPoint.

And that's about it for my story.

I think it's important if you want to do good design, to make an impression online, you have to define and think about personality.

Is my new website going to be a jitterish asshole? Is he going to be a very nice friend? Whatever, but think about it and make sure it's not average I think it's important to inspire creativity in the whole team.

Usually developers are the guys who have to do whatever designers did.

And I think it's a waste of creativity there.

I would say start from the future and build tomorrow.

And I would also say, if you like all this a brand-based design, be sure to come and chat with me.

Because good developers are always welcome.

[APPLAUSE] Questions-- raise your hand and someone will make their way to you.

Questions? Yes-- yeah, one second.

Here you go.

(audience) If you want to make it user friendly, in the from fields, where you're coming from, why not geolocation used in the browser so it will be filled in automatically? I'm not sure if it does that on the mobile version.

I don't use that one anymore.

It's not there.

But on the apps, it does that.

And most people use the apps.

We have apps on the three major platforms.

So we didn't bother to update the website.

OK.

We actually got one piece of very bad feedback on this site, which is a funny story.

Was one old lady writing us an email.

"I really hate what you've been doing.

And you removed all the fields.

And I can't input a street and an address number anymore.

And it's horrible.

I can't use it anymore."

Well, you know, it's you're making the next step.

And you're making it feel like Google.

And you're making it intelligent.

And then people used to the old ways start to complain.

Which was funny in a way.

The simplified UI was just-- she wanted the control of having 20 form fields.

Yeah, understandable.

Yes-- (audience) So a client came and asked for a redesign of a website.

And you sold him the whole rebranding.

Budget wise that's a huge difference.

How did you get them to comply with that? We looked them deep in the eyes.

No, really, it's simply a matter of outside view.

They had this inside view of what they were doing.

And we as an agency have the privilege of an outside view.

We could show them how they were perceived, what they were doing, what the future would look like if they were going on like this.

Because there is a lot of competition coming into the area.

And it was really-- we could show them at the time that they had to do this rebranding or die.

(host) Right there, right behind you, [INAUDIBLE].

(audience) Thank you for mentioning copywriting.

You're welcome.

(audience) And a question, was it hard to convince the client to have a copywriter in the process? Well we didn't really do much convincing.

We just went ahead and hired him.

(audience) Good.

(host) The left.

(audience) It's OK.

I was wondering about the big visual.

Because when the redesign came, there was the one that I was most shocked about.

Like there's a huge image on the background.

And it's also mobile.

Can you explain something about the design process behind that? And did it take a lot of convincing? Because now it's misused for advertising, but there's these random images on there of people almost missing their buses.

Or maybe that's my interpretation.

[LAUGHTER] Yeah, the whole point of the images is to make the planner the central element, design wise.

So it's the only white block on a big image.

That's the core functionality.

And the second function of the image is to make it more personal, to make it more human, to make it warmer than just the previous robot site.

And we did a whole photo concept for that.

So it's all very detailed in what kind of person should be there.

What they should be doing.

Where they should be looking.

What kind of light and color we want in the photos, all inspired again from the brand personality there.

Good question.

Yes, you have a question? Yes, last one.

(audience) Forgetting about the whole brand personality thing.

Did you guys do usability testing on the new version versus the old version to compare and get to see which one-- like A and B testing or anything like that? Yes, of course, we did lots and lots and lots and lots of user testing, especially on the suggestions.

They are very hard to get right.

And we did lots of improvements there.

And we are still doing user testing.

It's very humbling.

I personally love user testing.

And we're not done yet.

So there is a lot still to be improved.

That's great.

Yeah, it's always hard to-- sometimes it's hard to convince a client to spend on user testing, but I think-- Yeah, they say, "well you are the experts.

We don't need user testing."

(host) That's great.

Thanks, Anton.

Thanks very much.

[APPLAUSE] You're welcome.

[APPLAUSE] (host) Next up-- [APPLAUSE] Well good afternoon, everyone.

Thanks for being here.

My name is Elaine Oliver, and I'm going to tell you about the new Rijksmuseum website.

The website launched about a year ago, October, 2012.

Since that time it's been very well received.

And you can see in the third quote, you don't even have to go to the museum anymore.

And that's Jeroen Gijsman's mom.

And you're wondering who is that.

Jeroen Gijsman is one of our developers.

He showed the website to his mom.

She really liked it.

And if she likes it it must be good.

So I'd like to start a little bit by talking about the team.

First of all, the website is a collaboration between three groups, the Rijksmuseum of course, Fabrique Amsterdam, which is a design and branding agency, and of course the same agency who did 9292, and then Q42.

That's my company.

We tend to specialize in the technical realization of websites and web applications.

But I'm one of the people that's on the edge of that.

I'll tell you about a minute.

Here are just a few of the people involved, not even all of them.

Working on this kind of a huge mufti-disciplinary team is a lot of fun.

But it's also pretty challenging.

It takes a while for everyone to get used to each other, figure out what each other's role is.

Speaking of roles, this is me.

My role in the project was to translate the design composites to HTML and CSS.

I am also largely responsible for a lot of the responsive behavior of the website.

And they wanted me on the project, I guess, because I have this art background, the idea of going through that process didn't intimidate me.

There are some developers who are certainly capable of doing it.

But they're a little bit like, no I don't want to touch that.

I actually think it's fun.

So going further, I don't think I can really tell you much about the technical aspects of the project unless I talk about the vision first.

Because the vision is the thing that really drove the design process, drove the development process, and makes the website what it is now.

The first, and I think the most important part of the vision, don't bring the people to the art.

Bring the art to the people.

What do I mean by that? On the Rijksmuseum website, there are more than 140,000 works of art.

They are available to see at high resolution on the website.

They are also available to download.

So you can download an art object-- we call them that, sorry-- you can download this work of art from the website for free at high resolution and do what you like with it.

So if there's one thing that I could point to about the website that's really innovative and really motivated me to work on the project was simply this idea that we're going to open this up.

And what the website also does is it allows people to interact with the artwork in a way that's not possible in the museum setting.

So good luck getting this close to the painting in the museum without tripping an alarm.

And I'm going to take a small aside here.

I was not directly involved in the building of the zoom engine.

But I would feel very remiss if I didn't tell you something about it.

Because it is one of the main functions of the website.

My colleague Remco Veldkamp is the one who did a lot of the work on zooming.

What he did is he took a JavaScript library called Leaflet, which is used for maps, then modified it so that it could do continuous zooming.

And then there was the whole tiling process.

Let me get my stats here.

OK, and our back-end team was also involved in this.

So when the site launched, there were about 6,000,000 512 x 512 pixel tiles.

That is all 140,000 plus works of art at all possible zoom levels.

And I think it's one terabyte of data.

And I've lost my place here in my paper, sorry.

OK, one terabyte of data stored in the Google Blobstore, or the Google App store.

the Blobstore, and then delivered by the Google content delivery network.

Now what I've just told you gives you a really good sense of the scale of the project.

But there's also another aspect to scale.

And that is, even though as developers we had to support everything from desktop to mobile in one website.

The emphasis of the design is tablet first.

This is the target audience for the website, two people enjoying an evening together, on the couch, surfing the website with an iPad.

That was really-- every time that I was working on a page, that was the vision I kept hearing over and over again.

And so if you look at the website and how it turned out, it begins to make sense.

We've got these big huge buttons, very touchable.

It's also very colorful, a lot of emphasis on the Images, very simple and also very personal.

The Rijksstudio, which you can get an account on for free, is kind of like its own social networking platform that revolves around art.

You can go through the collection.

You can make snippets of different works.

You can see here this collection focuses on fire.

And then you can, of course, share that with other people.

So it's kind of like you're taking these works of art and making them your own.

So in the next part, of course, it's wonderful to have a vision.

And it was certainly a driving and motivating force for all of us on the development team.

But when it comes down to it, you still have to build it.

And so there were many challenges with this website.

I couldn't really talk about all of them.

I'm just going to talk about the one that I was really closely involved with.

And that is, you take a design concept.

You turn it into a living website.

And it needs to work on most devices and browsers down to IE8.

And on top of that, your starting point is static visual composites.

So here, these are just a few of the composites that we worked from.

You'll notice that they're all optimized for 1024 wide.

There were a few instances where the designer said, you know, we'd really like this to happen when the screen gets smaller.

But most of the time that was me and a couple of my colleagues sitting there with the screen figuring out, OK, these columns are too narrow.

It's time to add a media query to this.

Or this thing needs to go away.

Or this thing goes under this other thing, or maybe it goes the other way around.

You may think, well gosh, that doesn't sound very interesting.

But there was a lot of we called it [SPEAKING DUTCH], quality pressure on the project.

And the client, all of these little details, they would notice all of them.

So we certainly consulted with the design team about the decisions that we made.

But that was something that we really had to pay a lot of attention to.

The other thing though, as I'm sure that you all know, if you're building an all-in-one responsive website, media queries are not the whole story.

So here is just a laundry list of the things you have to keep in mind.

Again, a list I'm sure you're familiar with.

But when you are estimating how long it will take to build something, it is really easy to forget all of this.

And In the beginning of the project I'm certainly guilty of forgetting all of these things.

But it got better.

So in closing, I'd just like to mention a couple of solutions, things that I think we did right that kind of worked for us.

First of all setting boundaries.

So I mentioned support for IE8.

IE8 is not responsive.

It does not have rounded corners.

It does not zoom.

I think it looks pretty good.

But I think we all kept our sanity by saying, you know what, it's available.

It's going to look good.

It's going to be functional.

But we're not going to try to make it do all of the other things that the other browsers can do.

Again, the focus on iPad and IOS.

At first we did not do a lot of testing in Android.

Now I have an Android phone.

I use Android all the time.

I like Android.

So maybe I know that wouldn't be a very popular decision with everyone.

But again, saved our sanity.

When you have to build something that quickly, and it has to look that good, sometimes you just have to make choices.

Another really important one-- and I have to give our project manager Jasper Kaiser credit for this-- what can happen in a lot of these kinds of projects.

You're doing agile development.

It's your first sprint.

And there's high expectations, a lot of pressure.

And then somebody says, OK yeah, well logically let's build the home page and the main navigation.

A small problem there, the homepage and the main navigation are usually two of the most technically complex and politically sensitive functions on the website.

So our project manager said, no, these things are not ready to build.

There is still too much debate.

We're going to wait.

And that was one of the best decisions that we made.

Because when we did build it, which was roughly in the middle of the process, we were ready.

Also setting priorities-- and in order to do this, we used agile design and development.

We did estimation of the next sprint as a team.

And I think that really-- this is our snapshot of our Scrum board, by the way-- I really think that helped, especially with the client.

You know, the clients they want to ask for everything.

But when you've got this kind of structured estimation process in the picture, it really helps them keep time and budget in perspective.

And it helps the perfect from being the enemy of the good.

And this is a little plug for another aspect of my role in the project.

One of the other sanity saving things that we did was to develop an Object-Oriented CSS framework.

And I know that Object-Oriented CSS is kind of controversial.

So I'm not going to just suggest that you have to take that approach.

But certainly having a CSS framework, it helped us build new pages, very quickly.

We also had some responsive classes in there.

So we'd add a class that said, tablet portrait one column.

And so that way you could really get a page up and running very quickly.

So it was very fast design in the browser.

It helped us stay flexible.

It helped us build tolerances for design variations, which can be an issue when you've got all of these composites.

And if you're not paying attention, you can, as Ed mentioned, end up with all these different colors of gray.

And of course, it's also helped keep the size of our CSS file under control.

It's not quite where I'd like it to be at the moment, but it's shrinking.

I don't know how that happened, but I'm really happy about it.

So with that, I think I'm ready for questions.

[APPLAUSE] First up, if I can ask.

The original persona that you were designing for, like the couple on the couch with the iPad.

I wondered, know that the site's been out for some time, I imagine you've collected metrics and you kind of know.

So how does that match up? I was looking at those before I came over here.

Because I knew somebody was going to ask that question.

I couldn't figure it out.

What I can tell you is the client is really keeping an eye on the Rijksstudios.

That's kind of the social networking aspect of the site.

And I believe there are over 100,000 at this point.

And that's a year later.

So what I can tell you for sure is that people are engaging with the website.

The question is are they doing it on a couch with an iPad? Then that, I'm afraid, I can't tell you at this time.

Yeah, that's good.

All right, questions, raise your hand.

(audience) Yeah, over here.

Sir-- (audience) You mentioned that everything is publicly available.

We are all developers.

Is there some sort of API or something? Is there an API? Yes, I don't know if it's live yet.

But I know that we're working on one.

Yes.

Next question.

Over here.

(audience) I just downloaded "Night Watch."

All right.

(audience) Very easy.

But at no point during the entire time did anybody prompt me to agree to terms and conditions or notify me of a CC BY or any kind of licensing or anything.

And I was curious.

How did you get that to fly? I mean, certainly the people who have an interest in this art and its dissemination are going to be a little wary of how it's used.

Am I right? Yes and no.

First of all, you should have seen some dialogue that just said it was for your personal use, unless they've changed that aspect of the interface.

(audience) [INAUDIBLE].

OK, OK, there was that dialogue.

I was thinking, oh my goodness, we have a bug that we need to fix.

OK, I came onto the project right when the build started.

So as far as some of those very early decisions, political decisions, within the Rijksmuseum, I can't say that for sure.

But what I can tell you is that there is this theory out there among museum folk that when you publish a work of art in the media, it develops a kind of aura.

So I read a paper about this a little while ago.

And I think they were talking about "The Girl with the Pearl Earring."

That more people went to see that painting after the movie came out.

And you would think, well yeah but they saw the painting in the movie.

Well that's not what it's about.

It's sort of the object itself becomes this thing.

It's like the "Mona Lisa."

Everybody has seen the "Mona Lisa" on greeting cards, on television, you name it.

But because of that, it's acquired this kind of almost magical property.

And people go to the Louvre to see the "Mona Lisa."

So that's what they're hoping for.

And the downloading and making-- I guess we've seen a lot of Rijksstudios.

And I don't think anyone's ever done anything with a work of art that could be considered misuse, as far as I know.

And I think that overreaction to that sort of thing would probably be worse than just kind of letting it happen, as long as nobody is getting hurt.

(audience) OK, let me give you another example, which is kind of interesting, I guess.

The reason I'm going down this path is because recently I was writing a blog about an upcoming doc sprint that we are having here in Amsterdam on Saturday following this conference for webplatform.org.

We hope you'll come.

--shameless plug thing.

All right, all right, all right.

(audience) In the course of doing that-- the blog, not this shameless plug-- I was looking for images to put on the blog.

And I came across this one that somebody had mashed up using a laptop and Vermeer's-- I forget what this is-- "Lady and Her Maid."

It's a woman sitting there with a laptop.

It's a mash up of the original.

So I guess the question is, is that OK? This guy-- It's OK.

In fact, you are encouraged, if you do something really creative, you can upload your creations onto the website, If you develop a Rijksstudio account.

(audience) OK so now, as Paul Harvey-- some of us are old enough to remember-- would say, the rest of the story.

So this guy-- I didn't do this myself.

Somebody else did this mash up-- Scott, we're going to take one more question in the back.

(audience) OK real fast, and he put a CC BY license on that.

So I don't know if that's cool.

I am probably the wrong person to answer that question.

But I certainly know who I could ask, if you're curious, if you'd really, really like to know.

Question, right there in the back.

(audience) OK, really short question-- the scans look absolutely gorgeous.

But what kind of bandwidth are we talking about monthly? Oh goodness.

Well I imagine it's quite a bit.

Unfortunately I can't give you a hard figure.

But I know that the nice thing about working on a mufti-disciplinary development team, you get to see all sides of it.

So I also see-- I work next to the back-enders every day.

And I see all the things that they do to manage the server load.

I know there's a load balancing solution involved.

So that should give you an idea that it's not trivial.

OK, I think we're going to wrap it up there.

If you have any more questions, you can talk to Elaine afterwards.

Elaine, fantastic work on the museum site.

It's fantastic.

And thank you very much for presenting it.

Thank you.

[APPLAUSE] (host) All right so--