Skip to main content

A frontend crammer

Posted by: , Posted on: - Categories: Links, Tools, Transformation

I’ve spent the past few months as part of a team working within the Land Registry alpha. Part of your role as a GDS person within an exemplar is to help existing staff work in new ways and pick up new skills, particularly teams who may not be used to building products for the web.

As someone who often does front end development, I ran a "cram session" with the Land Registry developers. Part of this exercise was to gauge skill and interest levels in the group and make sure we had a balanced range of skills across the team — some people know a little about lots of things, and some people know a lot about one or two things. So it's helpful to know who understands what from the outset.


The crammer was structured like this:

  • An initial question and answer session to gauge experience and interest
  • Demonstrate the fundamentals of marking up an HTML document
  • An “exciting and fun” pen and paper exercise
  • More things to consider when marking up a document
  • A whirlwind tour of related technologies
  • Further reading and resources

Gauging interest

It’s interesting to ask an array of developers (sorry) of all shapes and sizes what they think of front end concepts such as “semantic HTML” or “progressive enhancement”. At the Land Registry, people ranged from those with a specific interest to those who were less focussed on the markup side of things.

The fundamentals

First we all looked at a page of plain text. Then we looked at the same content marked up using HTML. Then we discussed the differences, and what effect the markup had on the content.

If I was on the receiving end of this exercise, I’d probably get my grump on and say it was annoying and condescending. However, an exercise like this removes lots of considerations and allows us to focus right in on the core of what markup does. It also shows us what a lovely and tolerant bunch the Land Registry devs are when confronted with someone like me.

We reviewed the ways HTML can:

  • link to other content
  • add structure to data — a good example being a table
  • add structure to content — creating distinct sections, layers of importance and so on
  • enhance content — expand abbreviations for example
  • enhance and make concrete tone — the <strong> and <em> tags for example

This is the essence of markup. At root it’s not about browsers or devices, it’s about adding meaning, structure and the ability to link to other content. This is why visual tools can still be problematic — one of the most straightforward and efficient methods to give meaningful structure to content is to mark up by hand.

Now for some “fun”

I’d printed out some web page visuals from GOV.UK onto A3 paper. Each participant was given a print-out, a Sharpie, 15 minutes and told to mark up the document.

This exercise is something GDS have been known to do in job interviews, and you can often see developers helping designers learn markup in this way.

A fun thing to experience is a large gang of developers giving you side eye when being asked to "mark something up" using paper and pen. What a nice patient bunch these guys are being.

As this group were from varying ends of the developer spectrum, the results were really interesting. We had considered semantic markup replete with telltale existential crises over source order. We had “view” style sectioning of content based on business logic. And everything in between.

This kind of marking up exercise can be a lot of “fun”, and it allows people to demonstrate and discuss their thought processes quickly and easily.

(Yet) more things to consider when marking up a document

There are additional considerations when marking up content for display. We discussed some of them:

  • We’re not quite at the point where source order can be separate from the envisaged visual display
  • We need to be aware of other technologies that mesh with markup — think of microformats / microdata, ARIA roles and so on

Related technologies

For the last part of the crammer (only one person had nodded off by this point) I gave a very quick overview of the “other two” technologies that front end developers end up very concerned with:

  • CSS — binding visual styles to markup within a web browser
  • The Document Object Model (DOM) and the role of Javascript in affecting behaviour in a browser

Why only touch on these lightly? Progressive enhancement is why (IMHO). Solidly marked up content is the fundamental part of the web experience, and so we need to give it the attention it deserves.


Last but not least, I gave out a link to a list of resources assembled by myself and various designers and front enders at GDS. The one restriction was “let’s try to keep this short and simple” — I find there’s nothing worse than being presented with thousands of links at the end of a session. So the disclaimer is that this is by no means a complete or exhaustive list.

When I asked at GDS, what was interesting — and reassuring for an old timer like me — was the presence of seminal reads such as Designing With Web Standards by Zeldman.

See the list at the end of this post.

So, how was it for you?

Some Land Registry developers had a real interest in the front end and became our front enders in the alpha. Others were perhaps more intrigued by building lots of fancy microservices with Paul Downey and Mat Wall. So it goes.

Overall the session went pretty well. I think it raised the visibility of front end as a “thing”, and gave an indication of some of the complexity involved. I also hope that it embedded the idea of strong markup as a fundamental piece of modern web development.

The list

If you're interested, here's the list of resources:






Structured data in HTML






Online training (basic)

More reading


Sharing and comments

Share this page

1 comment

  1. Comment by Andy Porter posted on

    I'm, Andy, the one with the knees on show. I worked with Mat extensively after this on prototyping for user research. Mat was great, as was the session - which really helped us all. He's far too modest.