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]