Next talk kind of calls into question the benefits of rising markup.

And I'm particularly interested in this one because I'm a fan of progressive enhancement, so I'll be sitting in the front row with a sniper rifle, just in case things start to get a bit ugly.

So, here to tell us about it, and hopefully make it to the end of this talk, go slightly nuts for Nathan Ford! [APPLAUSE] Hello.

Thank you for having me, Amsterdam.

It's a beautiful city, beautiful venue, beautiful people.

Everybody's so tall.

I've never felt so short and hairy in my life.

I'm here today to kind of dumb things down a bit, I think, after these brilliant technical talks that we've just seen from Daniel and Hayden.

I'm here today to ask what you might think is a stupid question, do we need to write markup? My background is in design so I'll excuse you if you think I might be a bit stupid, but I do ask this question with sincerity.

I often ask naive questions at conferences and on Twitter because I want to find the deeper truths behind them.

And I also want to try to find new ways of looking at old problems and I want to be more inclusive of people that might be new to HTML or CSS, new to what we do, and they might be asking themselves the same questions, right? So one of my new found heroes, Kathy Sierra, has a great quote on this.

I, myself, have been living this in my career up until now and I think this is a great attitude.

So, fearless questions, generous with answers.

Well, this talk is really just a series of questions exploring the history and the efficacy of one of the most common mundane activities we do, writing markup.

But first, probably a question a lot of you might be asking yourselves right now.

I'm going to skip the unimportant bits and just talk about my experience so you know where I'm coming from.

Like many people I know in this industry, I built my first website when I was in my teens in FrontPage in the late '90s and later I went to school for design, and there they pushed Flash on us.

So if you wanted to learn web design, it was just Flash.

But I did have one smart professor who clued me in that, HTML and CSS, that's going to be the future of web design.

So I went home that day, opened up Text Pad and started just writing and trying things and gained a little bit of experience that way.

And in my first job, I worked at a full service ad agency and I was only one that knew HTML or CSS or any of that, so I got to cut my teeth on some fairly large projects-- leading these large projects.

I lead a project, it was $100,000 website redesign for one of the largest mattress manufacturers in the United States and I delivered a huge pile of crap.

It was terrible.

But I learned.

I've learned a lot.

So in brighter days, more recently, I've worked with the team at Mark Boulton Design and the web team at CERN to help them find better ways to communicate, both with their audiences and internally.

So we did redesign their home page, but we also got to do some pretty cool other things that actually have more to do with web history because, as I'm sure you all know, the web was invented at CERN in 1989.

So we got to restore the first website to its original URL, which was pretty cool.

A team of people came over we had a hack date and we recreated the experience of the line mode browser.

So how the web was experienced right off the bat, you can go now in your modern browser and experience that.

And we created a lot of sites and different parts of sites that document and surface much of the web's early history.

So that was some pretty cool stuff.

Now I work at Monotype and I make tools to help designers make better decisions on the web.

So why do I tell you all this? Well, I want you to know that, while I'm technically a designer and I'm employed as a designer, I have a meaningful history with markup and I respect it deeply.

So I'm not just trying to take it down here.

I'm a web designer.

To me that means I code and I design.

Some of you might call that a unicorn, which to me makes no damn sense.

I mean, if you're talking about a badass hybrid, I mean, what's a unicorn a hybrid of? A narwhal and a pony? I mean, how about combining something more cool like a hawk and a lion? I think that's called a griffin, right? No, actually, by my definition of design, kind of like Hayden was talking about earlier, I'd say we're all web designers because we're all contributing with code or content or COMPS.

More on that later, sorry.

But this kind of idea of hybrids, this isn't fantasy.

This is the reality of working on the web.

You wear many hats and the most successful teams are cross-functional, the most successful individuals, too.

Either way, we're all building the same web together.

So if I care about markup, then why mess with it? I think really because working on the web is approaching maturity, if it's not already there.

The idea of the web, and with it, HTML, was released for public use without restriction by CERN over 20 years ago and since then, it's tracked pretty closely to the capability maturity model of software development.

I don't know how many of you are familiar with that? Basically, it's been abstracted, since then, to kind of apply to any processes, really.

So this is the model here.

So level one, the initial chaotic phase, I'd say this is definitely the early web.

WWW stood for the wild, wild west, right? And in this stage, it's defined as chaotic, unstable, and not very good for processes.

But in the early web, we were learning, we were trying things.

The second step is repeatable.

So I see this as kind of the Web 2.0, the social web.

Blogs, and specifically tech blogs, allowed us to share our successes and then build upon them.

So level three is the defined phase.

For me, I see this as web standards, right? So I know we may not be completely there, or we're continuing to specify things as we go, but because we can all in this room agree that standards are an important thing, I think this is mostly accomplished.

So definitions have become an important part of our processes.

Level four is the managed phase, and this is where I think we are right now and where we've been for a while.

We keep improving, we keep finding new, interesting ways of approaching our work, and a lot of the major themes in web design have been decided or will be soon.

But there's a danger here that we could stagnate.

So this is where I think we should be focusing.

So the pioneers have gone out and blazed all the trails, the wild west is mostly colonized, but now it's time to build skyscrapers.

Since you're here, I'd assume you're looking for efficiencies in your processes and while it's great you want to expand your skill set and things like that, I also think that an important component of your growth is spending less time doing the tedious aspects and having more time for learning.

So in my time writing HTML, over the past 15 years, I've often found myself asking, why am I doing this? There's mortals to combat and there's beers all over the world I haven't drank.

So can HTML be improved upon? SaaS, LESS, jQuery, CoffeeScript, they've found ways of making CSS and JavaScript much more powerful and less time consuming, right? So can we take HTML to the next level? Jeff Atwood, he has a great post about this from about 2008, and he was asking if HTML is a humane language.

For content purposes, he was looking at markup for the posts and the comments on Stack Overflow.

And so he dug into a lot of different markdown languages and try to find is there something that works better? And in the end, he came back to HTML.

So HTML is generally the better choice, according to Jeff.

And his basic reasoning is, HTML is simple enough, it's readable enough, and it's secure enough.

It requires no further conversion to be used on the web and a lot of us know it already.

So, HTML, pretty damn good already, right? So if we can't optimize HTML itself any further, maybe we can at least improve how we work with it.

So before we go any further, I think it'd probably be good to set some definitions, and with HTML, it's probably good to go back to the source.

No pun intended.

We all know the web was invented by Sir Tim Berners-Lee at CERN in 1989, and if you're interested in those early days, I recommend reading this book, "Weaving the Web."

This is Tim's own recollection of how things came together.

It's a bit of dry read, but there are some interesting bits to it.

So this is the first web server.

I actually got to see it.

I mentioned earlier I worked with the team at CERN.

And it's funny, maybe a little scary, but there's no security around this thing.

They actually had it appraised and the guy came back and said it was priceless.

You can't actually put a price on it, but it's sitting in a trophy case next to a door, so easy pickings.

This is the early web browser on that next cube that I just showed you and-- hey, look at that.

Edit.

It's right there in the first instance.

So the original web-- if you read Tim's book he talks about this-- it was meant to be editable in the browser.

So no CKEditor, no Drupal, no WordPress, just file, edit, save and basically, the markup was the database.

It was a crazy idea.

But actually, Tim ran out of time, so he just didn't have the ability to put it in so we're stuck with what we have now.

So I mentioned earlier that, when working with CERN, we put the first website back at its original URL, which is actually kind of a lie because we put the 1993 version of the website back.

So we had a bit of a web archeology project led by a guy named Dan Noyes over at CERN and we went back and tried to find the earliest version that we could surface, and this meant people digging through old floppy disks and things like that.

The best we could do was 1993, but if you go there today and view source, you might notice some interesting things.

So first of all, all cap tags and attributes and, hey, there's a header tag, but no head.

And there's a thing up there at the top, I don't know if you can see it, it's called the next ID and that actually turns out to be a tag inserted by the Next Step HTML editor that Tim Berners-Lee, himself, built. And he even described

this as bad HTML, which I think is funny because he just invented HTML, and he invented the thing that makes it, and then he's talking about how it's bad.

There's also no closing tags on the DL and the A elements, there's no HTML element, there's no IDs, there's no titles, there's no classes.

The name attributes here actually work like IDs.

I don't know if you remember that from a few years back.

So they're basically page anchors.

And I like this, one my favorite elements, the definition list, down from day one.

So for even more of this kind of fun, check out the first HTML spec while you're there.

It just kind of shows you how far we've come.

So this is Tim's own words about the design of HTML.

Many browsers, many editors, many platforms.

So how can we learn from this? HTML was always intended to be generated by machine, at least in Tim's mind.

HTML was intended for content.

It's not until 20 years later that HTML becomes a platform for applications with HTML5.

And, originally, HTML was intended for everybody.

And I think is the most important point here and I think this is the one place that we can improve.

So this leads me to some of my definitions.

First of all, I use markup and HTML kind of interchangeably I know, basically, HTML is a form of markup and markups a little bit more general term but from here on out, I'll say them whenever I want to.

So first of all, markup is not code.

Now this is a very personal definition for me but I find that it helps because a lot of people that are new to HTML and CSS, they think of it as code, and they think that it's doing something and they think it's complicated.

So the word code is problematic here.

But, actually, HTML's quite dumb.

It doesn't calculate anything and, mainly, it translates the intent of the content for the browser So that then makes HTML a form of communication and it constructs content in a way to promote understanding.

So that, for me, makes markup design and design is problem solving.

And we designers, we've been outsourcing our actual production for quite a long time to all sorts of machines, so this doesn't scare us as much.

So because there's no logic, HTML is actually pretty easy.

The only real challenge in it is remembering what tag to use where, things like semantics, and deciding the intent of the content, the actual thinking part.

So if it's easy, though, you might ask me, well, then why not just leave it alone? Let us just write it all out.

Well, there's this last part that I think is important.

Markup is unforgiving.

So for people that have never used it before, it's kind of difficult at first to understand what's going on.

So correct formatting, proper semantics, these things are crucial for successfully translating the intent of the content to the browser and other apps, and accessibility is crucial for humans.

Has anybody ever tried to teach somebody HTML? Great, yeah.

And it can be a little bit of a painful process at first and it can be discouraging because you don't have the feedback of what's actually happening.

Why? I didn't close that H1 tag, everything's huge on the page, what's going on? So these kind of mandates of proper formatting semantics, these create a steep learning curve for new users and makes markup scary when it doesn't really need to be.

So with this unforgivingness comes some cost.

It taxes our brains.

The first such cost is ego depletion.

So this is unforgiving systems that lead to unexpected results.

This leads to what Kathy Sierra calls cognitive leaks.

Did I close that tag? Is a title valid here? Can I nest this within that? These things tax our will power and our mental resources, and don't leave a lot of room for higher reasoning as we're going through our authoring process.

There's loads of experimental data to back this up.

In one of the most famous experiments on this subject, two groups of people were asked to remember in a number in one room and recall in the next room.

So it seems simple, but one group was given a number like 62, with two digits, and the other group was given something like this.

Got it? OK.

So between rooms there's a hallway and the participants chose whether they want cake or fresh fruit as a reward at the end of the experiment.

So as you might have guessed from where I'm leading with this, the people that had to remember the longer number chose the cake more often.

So they didn't choose the healthy option, the better option for them, they just gave into their cravings and went with cake.

So the experiment showed that even a simple cognitive load can alter our decision making.

So that makes me think that maybe when approaching markup for a bit of HTML, the sheer thought of how much you actually have to write to do things properly may change how you implement it, rather than just building it how it needs to be.

So another problem I see is that sometimes you just want to focus in and get your work done.

Now, flow describes a complete absorption in what you're doing.

When flow is achieved, it can produce intense feelings of enjoyment and feelings of competence and efficacy, which just sounds really nice.

That's the kind of thing I want to be doing with my days, right? So research into this area was made popular by this guy and I'm not going to attempt his name in public, so from now on, he's going to be known as MC.

So during the '70s, MC and his fellow researchers began looking at how artists get lost in their work and they called this flow.

And they described six factors that encompass an experience of flow.

So, for me, the act of writing markup, I believe, can run counter to some of these points.

And according to MC, all of these are necessary for a proper flow experience and specifically this one.

This one's important.

Is writing markup intrinsically rewarding? Sure, when you're first learning about how to write HTML, getting things to work is pretty exciting but that fades over time.

So if it isn't intrinsically rewarding, is it just a chore? So with a steep learning curve and little reward, the process of markup can feel kind of like an anti-flow, actually.

So this is my final problem, or perceived problem, with how we go about markup these days.

This is siloing, also known as an information silo.

So this one I've seen a lot in our industry.

It's a word we've used a lot in our research for Gridset, Typecast, Monotype, and we see siloing a lot and we actually have been looking at many different ways to kind of break down those walls.

So it's not exactly psychological, but more systemic to organizations.

Teams or individuals, they specialize over time and it's harder for them to then communicate with other teams and this is a problem because the best ideas come from getting away from the desk and talking to people, especially people that don't do what you do.

Steven Johnson has written an excellent book on this subject.

He builds on tons of anecdotes and psychological studies and describes the ideal conditions for good ideas as environments where ideas can be shared and built upon with limited interruption.

These are his words on it.

So they want to complete each other.

Good ideas want to complete each other.

But the laborious process of writing markup doesn't really lend itself to collaboration very well.

The perceived difficulty from other people on the team that see it as code, and they're a little bit scared of it, prevents them from understanding what you're doing and having meaningful conversations about what you're doing.

So markup becomes solely a front end dev or a front end development team's responsibility, which could be lonely and, ultimately, successful markup becomes a thankless job within your team or organization and you could use that positive reinforcement, right? Because positivity affects motivation and ego depletion actually, too-- what we just learned about.

So if we can't improve HTML itself, we can't optimize it, maybe by focusing on these few pain points, we can improve how we work with it.

So when optimization is no longer beneficial, abstraction sometimes helps us get to that next step.

For example, markdown is the optimization of markup.

Its subject matter HTML is ultimately the same, but every flavor of markdown finds efficiencies in different ways.

Optimization is not abstraction, though, and the mental model, or how the user achieves what they're doing, is the same.

They type it out, right? So WYSIWYG, actually, is more of an abstraction.

You're applying the idea of bold, not writing the tag.

The mental model is different.

So for a more dramatic example, let's look at calling a cab.

As a person who needs a ride, your mind already starts going through all of these things.

So you need to call the company, but maybe you don't have the number.

When you actually get a hold of them, you need to describe what you need but there might be a language barrier, right? You might have to wait blindly on a street corner somewhere and not know if they're ever going to show up.

At the end of your ride, you have to pay for it and you might find out, oh, they don't take credit cards, so now I need to get cash, right? And at the end, the receipt, I always forget the receipt.

So services like Uber and Lyft have simplified all of this-- all of this that you see here-- into this, at least at the point of need.

And I know there's questions about the efficacy or the ethicalness of those companies, but at least for the user experience they've got something right.

So one button, but behind that button is a whole series of efficiencies.

This is a pretty elegant solution that maps to a user need-- I need a ride, give me a ride-- and these companies, their growth have been astronomical.

There's a simple lesson here that the right model means faster uptake.

So remember, HTML is pretty damn good.

We can't optimize the markup itself but maybe we can change the authoring model to make the process faster, easier to understand, and with less room for errors.

Can we make it more approachable to designers and the other members of our team? So before we look and try to find the right model, let's look at what's already out there.

Of course, beyond just typing it out.

First, we have what I call the word processor model.

This is usually seen in CMSes and WYSIWYGs emulating a word processing environment, and it works really well for what I call inline styling and content styling-- bolds, italics, links.

But they're terrible for constructing an entire page and applying anything more than emphasis.

I also have the drawing boxes model, which is what designers like.

That's what we like.

We want it to work like Photoshop for the web and we just want to draw boxes on a screen and make it spit out perfect code.

That's great for people who don't understand markup, but I'm pretty sure everybody in this room knows that those kind of apps, what they spit out can be a major problem.

And me, I have a problem with the waste that's created because if you are generating code that you're just going to rewrite anyways, why not just stay in Photoshop and not learn all these other things? I just pass it along the front end dev team.

So these all fail because they try to encompass too much and their model is a bit skewed.

They try to take something that people are comfortable with and take it that next step.

So I'm kind of playing around with a new idea.

This is a bit of an experiment but my model is lists.

I've always kind of seen HTML as more of an inventory of what's on the page, and lists are great because they're easy to understand.

Everybody learns in grade school how to organize an outline and put together lists.

So this is the simple interface I've thrown together.

It's very rough but the basic idea is to allow people to create HTML like a list.

We have an inventory on the left, here.

You put your structure together in the middle and on the right you see the output.

At the top right, you see there's a way to preview and you can send it over for validation, as well, just to make sure that the tool itself is working properly.

And so this is an example of how it might all come together.

And I know the code on the right isn't as beautiful as I'm sure all of you write it but it's just an experiment.

So items on the left, they have a tool tips, or titles, basically, so they have suggestions for the use of the tags and you can double click anything in the structure to add attributes, which is nice because this is an opportunity for the app itself to suggest what you should use and maybe even make some things required.

Again, this is very quick, but it's enough to start learning.

So for the ultimate test, I asked my poor wife, just try to build a page, on camera, just from a sketch I gave her.

So I give her a few minutes to learn what the tags are, to kind of explore the app.

I told her bit about how the app works, or tool, I should say.

It's not really an app.

And here she is building a web page.

Now, my wife is a historian and a personal trainer.

That's her background.

She's never built a page of HTML in her life and she just completely shuts down whenever I start talking about this kind of stuff.

So, yeah, there she is building a header, though.

And I think we can just go ahead and skip a bunch of this.

So for the most part, I think she understood the model, and she worked with it all right.

And this is just feeding her a little bit of a sketch.

But in the end you see, here we go, valid HTML.

She built-- her first HTML page is valid on the first try.

That's pretty cool.

So now I know this might not be the perfect tool.

It's just an experiment, it's something to learn from.

But there are a few efficiencies that I found in this model that I like.

One, validation is no longer necessary and semantics are pulled up to the front.

So the tool itself can decide the validation.

That's the job of the tool, is to make valid HTML.

And semantics are now the main function that the user is thinking about.

What's appropriate and where? So also, this interface is a learning interface for the user.

The person that approaches this can learn about what all these tags are and look for the meaning behind it, and the tool tips aid in this as well so they can make better decisions.

This means less jumping over to Google, less stack overflow, less snarky comments on those sites.

So they can stay in the flow as they're working.

And lastly, smart defaults.

So we can remove all the stuff that doesn't really need to change all that much, things that we might put into a boilerplate, and things that are in the head and about 100% of the stuff that you'd put invalidating an e-pub.

This helps you get to what you're trying to accomplish faster, basically.

So further work on things like this could yield a few more efficiencies, if I had more time or as I progressed with this, I'm going to try a few things.

One I like the idea favorites.

So things like articles and heads and divs, they can all move up to the top, maybe even based on how much you use them.

Also, patterns-- you could easily save patterns into something like this and recall them whenever you want, because there's only one great way to write a block quote, right? And you have your opinion on that, so you should be able to do that whenever you want.

Also tools can take the responsibility for all the latest developments in the spec.

So instead of you having to remember all these things and go and Google them and pull them in, that becomes the tool's problem.

And also, they can retire the old things as they come about.

And probably most importantly, tools can take responsibility for things like accessibility.

So there's a psychological phenomenon called diffusion of responsibility, which means when you give everybody the responsibility to do something, it doesn't get done.

A person's less likely to take responsibility when others are around and they think, well, they'll do it.

They'll take care of it, right? So this way, the tool can take responsibility for accessibility.

So far, I've focused a lot of this on markup, but the same pain points and the same approach can also apply to styling.

There's lots of examples of small tools on the web to solve problematic syntaxes.

We see these a lot.

Right now your animations gradients and flexbox are kind of troublesome for people.

And these tools, when properly maintained, they keep up with the latest syntaxes for you, they apply all the appropriate prefixes, and they give you a UI to actually understand what you're doing.

Especially as a designer, when you're making a gradient, it makes it visual so you know exactly what you're getting.

I've experimented with this a bit, as well.

Gridset, a tool I've made for responsive web design, is basically just a robust UI for building your layout CSS and deciding what you're going to do with your grids upfront.

So I've also been-- since the company I was working for got acquired and now I'm working for Monotype alongside the people at Typecast, we've discovered other efficiencies, mainly centered around describing complex styling properties to designers that aren't as familiar with HTML and CSS.

So, for example, something like box sizing.

Now, on it's own, it's a difficult concept for somebody who doesn't have any experience with the box model.

But when you combine it with other properties, it starts to make more sense.

So pad in, pad out.

This could also work for border inside or border outside.

These are things that designers understand.

And for some limited application and content styling, floats and clears could be described with simple buttons.

And these small abstractions have actually tested quite well and this gives designers agency over what they're trying to accomplish.

It allows them to understand the implications of what they're doing and it also allows them to have better conversations with the developers.

So, I get my way and we make HTML and CSS so much easier.

We go five years in the future, we have tools that make this very simple.

What's left for us to do? Well, besides from the obvious, we can make more updates to the sites, try to keep up with changes more.

We have more time for testing, because we know that with responsive web design that's a crucial factor.

We've seen that a lot in our research.

So one of the goals I'd like to see is, I want to get home faster.

This is my cat, Batman.

Not the Batman, of course, but he is evil.

But at the same time, I love this little hell beast and I look forward to seeing him when I get home.

And I have a cat, another cat, a dog, a wife.

These are great things.

I'd rather get home to them.

So get home to your family, your spawn of Satan, your call of duty, whatever.

Also, we can spend less time doing, more time thinking.

We're humans.

We're not great at generating consistent output.

Computers do that like a million times better.

So we think, we communicate, and we imagine, and these are contributions.

So we need to spend more time-- or we can maximize our time thinking and minimize the actual tedious parts of doing.

So more time to think means more time to design the architecture on complicated sites and more time to document that architecture to distribute the knowledge that we've put into things, our hard work, across our teams, so they understand what's going on.

And when there's more markup responsibility across a team, that means everybody's thinking about things like, how do I make this content richer? How do I put more metadata into this so that it's easier for machines to understand? And how do I make better layouts and more enriching content experiences? And lastly, if we have more time, we can get involved more with working groups, deciding the future of how these things are shaped.

We can blog more, we can share more, and that's always good because we can also explore the adjacent possible, which is a great term.

It's actually a term that was introduced in biology to describe how evolution progresses.

So nature didn't just build an amoeba and then a turtle and then an eagle, right? Instead, the engine of evolution was fueled by a lot a little small steps into what's called the adjacent possible, what was possible at that moment.

So things like a wing that was regulating temperature on a bird all of the sudden becomes better for flight.

So these small incremental improvements connect over time into larger improvements.

Steven Johnson again, the guy I mentioned earlier, he explores this in that book, "Where Good Ideas Come From."

So he believes good ideas track along a similar path.

So we hear so much about the Eureka moments in science, but typically, great ideas come from slow hunches that mature over time.

So these are his words on it.

Each step leads to more possibilities allowing for infinite paths of improvement.

So in this way, even missteps can lead to success.

That thing I showed you earlier? It could be a terrible idea, but at least we can learn from it and move on and explore what's out there.

So right now, I've only explored a few of the possible paths of what we could do with our time.

But the question isn't really, do we need to write markup? It's just that, if we can find these efficiencies in our processes, then what could we do with our time? Thank you.

[APPLAUSE] Right, so come on over to the lounge area.

Which seat would you like? You get your pick of all two of them.

I'll take the closest one.

The closest one.

Yes.

That's a good idea.

So you were working at CERN.

I actually met Tim Berners-Lee.

I've only met him once.

I met him for the first time earlier this year and I-- because I don't think I get nervous in front of celebrity, but I was really nervous meeting Tim.

Yeah.

I just shook hands with him and the best I could manage to say was, fan of you work.

[LAUGHTER] It was like, thank you for a job, there's nothing else I can do.

Yeah.

So this system that you're talking about, do you see it as a learning tool or kind of like the end goal? They way we should all be creating pages? Yeah, I think it's more of training wheels.

So it's a bridge from completely not approaching HTML ever before to hey, I can actually build something, and doing that as fast as possible so that people can learn.

So how far down this road do we go in until we're sort of back at front page? And what process do you go through to remove those training wheels? So I think the important thing here is to think about the model.

So instead of drawing boxes on a page, like a visual view of building a page, I think we should think about how to just connect the dots a little more efficiently.

So instead of writing every single element out and every single attribute, maybe we can just make that a little simpler.

So I don't know if a lot of you have seen the most recent Dreamweaver? I know that's kind of a bad word sometimes but it's interesting, because they've kind of realigned the entire app just around putting attributes in the right place and making an interface on top of HTML and CSS, which is kind of cool.

But I think we can go even simpler than that.

I think when we try to make things way too complicated, then it just becomes a barrier for learning.

My first introduction to making a web page was using the tools that shipped with Netscape Navigator, and then Front Page, and then Dreamweaver.

Right.

And I think it is-- you're right-- it's a learning tool to be able to write something on the page and then go into the source code and see what is produced, and slowly wean yourself off the interface.

Yeah But that requires, I guess, the tool to do the absolute right thing to learn from, rather than it be a bad teacher.

Yeah and it's also kind of a lengthy feedback loop, right? So you type something over here and then you hit Save, then you go over here and you view source.

That's not as good as just seeing it happen as soon as you're doing it, right? So if we shorten those feedback loops, then the learning experience becomes much more enriching.

But how can you give feedback on, say, the right semantics are being used? The right elements are being used? That's a great question.

Yeah, I don't know.

I was hoping you would .

I mean, I think by educating, at least, and by providing an inventory that people can see what is available and know that, rather than just going for a div or something like that, I think that does help.

Working with Chrome dev tools, we see a lot of people that, their first way they debug is using console.log,

which is-- apart from alerts-- they're the lowest level thing.

But these tools have break points and stuff.

It seems like sometimes there's almost-- people feel like, going for the higher level methods, it's cheating somehow, even though it's there and it's easier and it's quicker.

Yeah, I think there is something to that.

There's always this idea of handcrafted that people love.

Designers love it, I think front end developers, we like it as well.

But there's always going to be a place for that.

What we really provide, as human beings, is thought processes, thinking, reasoning.

These things that are handcrafted and special, all those things will have a place, but I don't know that we need them in our everyday production when we're just trying to get the work done.

So what areas of the web do you think are stagnating at the moment.

You said it's part of process.

What you see as not moving as fast as it could? Oh, well, actually I don't feel that the web itself is stagnating or that even the specifications.

We're getting also sorts of great things.

In fact, in my time working with HTML, CSS, JavaScript, I've been stunned by how fast we've come recently.

But the processes, the way we work with things, might stagnate if we just are saying, OK, well, I can do this, so this is good enough for me and I'm just going to stick with this.

I think certain people, and I don't know who these people are, but they could-- that are placed well within the industries can start thinking about, OK, how can we be more inclusive with what we create? With the specification? With HTML, things like that? So that people that may not have a background in computer science or something like that, can feel comfortable walking right in and making an HTML page.

So you were showing the first web page ever made and that still works in browsers today, which is pretty incredible.

Yeah, totally.

But is it holding us back? What, the first web page? Well, no, but having that legacy, having that requirement? Oh, right, yeah.

Because one of the things that we get, like the first Android app, does not work on Android today.

Right, yeah.

And that, I'm pretty sure, is true the first iOS app.

Are we holding ourselves back with this? Well I think, actually, we hold ourselves back by not knowing where we came from.

And that's kind of the bigger issue, right? So if we think of ourselves as thinking individuals and we're bringing reasoning to this, then we need to build upon what's come before us.

So if we're constantly losing those early lessons, then we don't have-- we have to start all over each time.

So I think there's-- I mean, for me, like I said, my wife's a historian so she makes me think about these things, I like the idea that we have that history that we can go back to and learn from.

So part of what you were building there, it still requires the decision to be made of what element to pick for what.

Yes.

And do you feel that the semantic decision making, that's kind of what adds a lot of the drudgery to writing HTML? I know that when I was working at the BBC, if an email arrived on the sort of front end group that start with, should I use definition lists for? Then that was the point you cut power to the building, you sound the alarm, you get everyone out.

Yeah.

And get someone in to come and purge the server so that no one sees that email.

Yeah, I actually think that's the important part, though.

That's where the conversation should be because we need to make-- I mean, for marking up pages, we've got all these tools at our disposal and we need to use them properly, right? And if we're going to have different apps that are reading our pages and different people trying to learn and things like that, then we need to have some consistencies and we need to agree on things.

And that's where those conversations are very helpful.

So with your tool, the stuff you had on the side was the tag names.

Are the tag names themselves part the problem? We have p to mean a paragraph or a to mean a link, which is the especially weird one.

Yeah.

How can we get around those issues? Well, yeah, I think that's a lot a legacy that comes from those early days and that's kind of the mind of Tim at work, or some of the other people that were working on it at the time, and I think that's a difficulty.

But I think it's not so hard to say, OK, well p equals paragraph, right? So I was able to do that my wife when she was building.

I was like, OK, you want a paragraph? It's the p one.

So I think it's just about making sure that those things are visible and easily accessible, those definitions, so that the user understands what they're doing.

So how would you marry in creating a visual design with a tool like that, that still stays true to its semantic roots? How do you account for accessibility in a tool like that? Yeah, well, accessibility, I think we can make some smart defaults.

So when somebody pulls something in, just go ahead and put it on there and then have some overrides, of course, so that some people who know what they're doing can get in there and make it work properly, or how they intended.

And I think, in a visual tool, I still think the browser is one the best things you can work within.

It's always an accurate representation of what you're building.

And I still think that things like Web Inspector or, originally, Firebug, those are the best web design tools ever made.

So when you're saying we're all designers, that's something that I definitely buy into, but how do we best structure teams and processes to make that happen? To make everyone feel like they're part the design? Well I think what Daniel was talking about at Etsy, making everybody responsible for some bit of the code, and maybe even some of a bit of the design, works.

Breaking down the silos is important.

And one thing that we've been doing at Monotype is looking at cross-functional teams.

Smaller, cross-functional teams set against a goal rather than we've got our dev team over here and our back end guys over here and designers over here, so that everybody is always communicating.

I think the important part is some people find it tedious to talk to people and get interrupted, but that's actually work, too, to talk about these things and bring everybody along with you.

So you're an ex-Flash developer, right? That was sort of part-- No, I kind of just sidestepped that as soon as I could.

[LAUGHTER] Yeah, I never really got on with Flash.

So do you have much experience with the editing software? Was there anything that you would take from that into HTML? I don't know.

So I think that's still kind of that drawing boxes model.

That's how it's always felt to me.

So I want text here so place it right here, but that's not really how the web works because there's the-- the dom model basically decides a lot of that and styling can be quite tricky to get it right where you want it.

So I think that it actually sets up people for failure.

So designers that are coming in saying, oh, I'd rather just use Flash because I can do it this way.

Well, that's not exactly how things work.

So it's a barrier more than it is a help.

I've worked with some designers in the past that are really adamant against learning to code, learning the sort of materials that the web is made with.

Yeah, me too.

Yeah.

And what they all stick with is something quite static, such as Photoshop.

Is there a call for something in the middle? Like some kind of design tool that isn't technical but has the material of the web? Like it has the flexibility, it has some of the style inheritance stuff? Or should it just be, designers, come on.

You've got to learn CSS.

I mean, I would like to see designers learn HTML and CSS, all of them, but that's not gonna happen.

I don't think there's one tool that's going to sit in-between these two processes.

I think there's going to be tons.

And it's really about piecing together the tools that work for your workflow.

And I think that's, again, where a lot of these different models get it wrong, like the Flash model, the drawing boxes model.

It's because they don't think about the workflow, they just think about what the designer wants or what the user wants.

So, yeah, I think there's going to be tons of little-- there's little efficiencies we can make along the way to bring designers along a little better.

Are there tools out there already that you feel are looking in the right ballpark for this kind of stuff? Or is everyone getting it wrong in this area at the moment? Oh, no, there's tons.

I showed a few that are graphic interfaces for the new syntaxes, like animations and gradients and things like that.

Flexbox is something I'm still trying to wrap my head around.

So I like tools that help me play around and figure out what's going on.

And, yeah, I mean it's something we try to do with the tools that we're building at Monotype.

Excellent.

I'm trying to think of some off the top my head and I'm just forgetting a load of great stuff that's out there.

But there's tons of people doing it.

It's very exciting.

I think it's a good time to be a designer moving into front end development.

Cool.

Thank you very much.

Nathan Ford, everyone! Cool.

Thanks.

[APPLAUSE]