HTML: the language of the web

At times we use ☝️ and 👇 to make it clear whether an explanation refers to the code snippet above or below the text. The sign is added to code examples you should run yourself. When you come across a DEBUG box, we offer advice on how to debug your code—this may help you with your assignments. Neither DEBUG nor OPTIONAL content are exam material.

Table of Contents

• Required & recommended readings and activities
• Learning goals
• Web sites vs. web applications vs. the web as a platform
• Cross-platform applications
• Web design basics
  • Rule: Don’t make me think
  • Rule: Minimize noise and clutter
  • Rule: If you cannot make it self-evident, make it self-explanatory
  • Aesthetics matter (of course!)
• Usability testing: expectations vs. reality
• Performance metrics
• HTML5
  • The move towards HTML5
  • Who decides the HTML standard
• Self-check

Required & recommended readings and activities

• Required readings:
  • Getting started with HTML @MDN
  • HTML text fundamentals @MDN
  • Document and website structure @MDN
  • Introduction to HTML forms @MDN (skip over the section on Basic form styling, we will cover this topic in a later lecture).
• Recommended readings:
  • Chapter 3 of the Definite Guide to HTML5.
  • A blog post on the use of animations to enhance the user experience.
  • Examples of what modern web technologies can achieve in Chrome (if you use another browser, not all examples may work as expected).
  • Atomic Design by Brad Frost
  • Laws of UX: web design principles explained in short snippets.
• Relevant scientific publications:
  • Fernandez, Adrian, Emilio Insfran, and Silvia Abrahão. Usability evaluation methods for the web: A systematic mapping study. Information and software Technology 53.8 (2011): 789-817.
  • Sonderegger, Andreas, and Juergen Sauer. The influence of design aesthetics in usability testing: Effects on user performance and perceived usability. Applied ergonomics 41.3 (2010): 403-410.
  • Mathur, Arunesh, et al. Dark Patterns at Scale: Findings from a Crawl of 11KShopping Websites. Proceedings of the ACM on Human-Computer Interaction. Vol 3. CSCW (2019): 1-32.

Learning goals

• Apply web design principles during the design stage of a web app.
• Explain the ideas behind usability testing and employ it.
• Employ HTML.

This lecture does not cover how to write HTML, this is covered in the required readings for this lecture. At the end of this lecture we provide historic context to understand/appreciate the current state of HTML.

Web sites vs. web applications vs. the web as a platform

The W3C has many working groups, among them (until 2016) the Web Applications (WebApps) Working Group whose goal was as follows:

1
2
3
4
5
6
7
8

As web browsers and the web engine components that power them become 
ubiquitous across a range of operating systems and devices, developers 
are increasingly using web technologies to build applications and are 
relying on web engines as application runtime environments. Examples of
applications now commonly built using web technologies include 
reservation systems, online shopping / auction sites, games, multimedia 
applications, maps, enterprise-specific applications, interactive design 
applications, and PIM (email, calendar, etc) systems.

In 2017 this group was superseded by the Web Platform Working Group which has a similar goal (but not written up as nicely). The working group is responsible for a number of web technologies that move us closer towards the vision of the browser as the operating system.

Cross-platform applications

Do web technologies also help us to create desktop apps or mobile apps?

Indeed, they do! Electron is an open-source project that enables us to build cross-platform desktop apps for Windows, Mac and Linux with HTML, JavaScript and CSS—the very technologies you learn about in this course.

Electron itself uses Node.js, the server-side JavaScript runtime we cover in a later lecture together with Chromium, an open-source web runtime.

The major benefit of Electron should be clear: instead of writing three separate desktop variants (one for each operating system) you only have to write and maintain one. New features are integrated in one application instead of three, which reduces feature delivery time. For these reasons, many well-known applications today are built on Electron, including Visual Studio Code (the IDE we recommend you to use), the Slack app, Atom and many, many more.

If you ever wanted to know how Windows 95 looks like, there is an Electron app for that as well. It looks like this :

^{Windows 95 stuffed into an Electron app.}

On the downside, such a cross-platform approach usually brings with it considerable overhead—each application for instance bundles Chromium, which means that even if your app is not doing anything else besides Hello World it will be at least 30MB large. As a concrete example, the unzipped Windows95 Electron app is more than 454 MB in size, while the original Windows 95 operating system required about 40 MB of disk space.

While Electron focuses on cross-platform desktop applications, initiatives with a similar goal for the mobile world (i.e. generating native apps for Android/iOS from HTML/CSS/JavaScript) exist as well. By far the most popular is React Native. Before you can use it though you will have to learn React, a very popular JavaScript library for building user interfaces that is being developed by Facebook.

Web design basics

The design of a meaningful user experience (“UX”), which for us is narrowed down to the design of web user interfaces (UIs), requires insights primarily from psychology and human-computer interaction.

While this is well beyond the scope of our course, we present here a few basic rules that web applications should adhere to. These rules may seem obvious, but in practice are often ignored. This lecture is partially based on the book Don’t Make Me Think, Revisited (2014) by Steve Krug. In the following sections we go over a number of Krug’s rules with concrete examples. Note that the book may look somewhat outdated (in the end, web applications seven years ago looked quite different from today), however the principles are general enough to remain applicable to this day.

Before you continue, head to https://userinyerface.com/ and “play” its game: attempt to fill in the form as quickly as you can. Along the way, you will come across many extremely annoying user interface features that you have undoubtedly seen elsewhere on the web already. This (probably horrifying) experience shows why good UI design is so important.

Rule: Don’t make me think

The way a web site or web application (we tend to use the terms interchangeably here; the rules apply to both apps and sites) works should be self-evident; the user should not have to expend cognitive effort to understand what she can do.

Consider this example of ebay.com:

^{Screenshot of ebay.com taken on October 11, 2019.}

Here, it is very clear for the user what she can do: search for products, browse through the available items via product categories and shop for discounted electronics.

Contrast ebay with the following older example from koopplein:

^{Screenshot of koopplein.nl taken February 8, 2014.}

It is not self-evident for the user how to act to achieve her goals and major questions are raised:

• How do I get to the offers?
• What if I want to look at offers from Delft and Rijswijk instead of one or the other?
• What is all this text about?

Good to know: In case you wonder how it is possible to go back in time and look at older versions of a web site (as today’s koopplein.nl presence looks considerably better), head over to the Wayback Machine, maintained by the Internet Archive whose mission is to archive the web. The Wayback Machine of course does not archive the entire web (this would be impossible), but it does take regular snapshots of more than 390 billion web pages, including those of koopplein - take a look.

When naming and formatting links, buttons, section headers, etc. adhere to established standards and be clear instead of clever. For instance, a company’s web site that has a link to its current job offers should use as link text Jobs or Vacancies (clear to the user what this link is about) instead of Interested? or Join us! (less clear).

Similarly, there are established style standards of how to format a link: in the early years of the web, blue underlined text was synonymous with a link and thus we are now stuck with the saying 10 blue links as a synonym for web search results.

Users should also not get lost within a web site. A site should provide users with information on where they are and on how they arrived at that point. Ebay for instance leaves so-called breadcrumbs:

Lastly, it should be easy for the user to distinguish different parts of a site such as advertisement vs. content. Below is an example from Google that does a poor job in this respect. It is not obvious on first sight that the first search result is indeed a paid advertisement (the little Ad tag can easily be overlooked) instead of a so-called organic search result (i.e. one the search algorithm surfaces at the top ranked result) :

^{Google search result page, September 8, 2020.}

A few years ago (August 15, 2013 to be precise) Google was more forthcoming when it came to clearly notifying its users about advertisements :

^{Google search result page, August 15, 2013.}

It should be mentioned that Google is not the only offender here, take this example from Twitter which is similarly poorly designed in terms of content distinction between organic tweets and promoted (i.e. paid) ones:

^{Twitter, September 7, 2020.}

The Google/Twitter examples above are of course not accidental: user interface designers are not accidentally trying to disguise the fact that those are ads (also known as promoted or sponsored content). This is done on purpose: we know that users are less likely to focus their attention on ads if they recognize them as such. Disguising them to some degree means a higher likelihood of users paying attention to them. A higher engagement level means a higher financial return for the company. This is what is known as a dark pattern, more specifically the pattern of disguised ads. Formally, “dark patterns are user interface design choices that benefit an online service by coercing, steering, or deceiving users into making unintended and potentially harmful decisions.” A recent study of 11K shopping websites found dark patterns in more than 10% of them.

Rule: Minimize noise and clutter

This rule does not have to be explained in great detail. Here is an example of ZDNet and how it looked in 2001 and 2014 respectively, to make things clear:

^{ZDNet crawled on March 31, 2001.}

^{ZDNet crawled on August 31, 2014.}

While it is not hard to go back to old web designs and find faults in them (a not-too-serious look at the history of web design can be found here), it should also be mentioned that in those times, every single HTTP request/response pair was time-consuming (the Internet was slow) and expensive. It made sense to push as much content as possible into a single page which could then be sent to the client in a single HTTP response.

Rule: If you cannot make it self-evident, make it self-explanatory

Self-explanatory sites require users to expend a small amount of cognitive effort, that is, the mental effort it takes to engage in a task. When a site is not self-explanatory, a small amount of explanatory text can go a long way. In today’s mobile world where a lot of content is accessed mobile first, it is vital to keep the mobile user in mind who has to deal with a small screen, a touch-based interface and possibly many distractions while surfing the web.

A positive example of this rule is the following Surveymonkey splash screen:

^{Surveymonkey crawled on December 1, 2013.}

In contrast, take a look at this entry page of a Dutch business and take a guess at what it does:

^{Screenshot taken October 11, 2019.}

The entry page (or home page) of a web application should answer a number of essential questions, none of which are answered in our example:

• What is this?
• What can I do here?
• Why should I be here?
• What do they have here?

As a side note, another serial offender of the entry page checklist are university home pages as immortalized in this xkcd comic.

Lastly, avoid happy talk, that is text without any content for the sake of adding some text (e.g. a welcome message).

Aesthetics matter (of course!)

This may be obvious, but the look and feel of an application of course also influences both the users’ perceived usability as well as the actual usability. An insightful piece of research conducted by Sonderegger & Sauer has measured this influence. They conducted an experiment with an objectively ugly and an objectively good looking mobile phone prototype that had the same actual usability: not only did the study participants rate the ugly phone as being less usable, they actually performed worse in a given task than the participants receiving the good looking device.

Usability testing: expectations vs. reality

Our expectations of web users are often not grounded in reality. We may expect users to be rational, attentive and having a clear goal in mind. Instead, the average web user:

• quickly scans a web page (not even reading it);
• decides within seconds whether or not a site is worth their attention (research on so-called dwell time has shown this again and again);
• clicks on the first link they find;
• depends a lot on the browser’s back button (which can causes issues for web applications);
• does not read instructions.

A web application should be designed based on user reality. Usability testing is an important step to create a well-designed web application. The development cycle consists of designing-testing-reviewing:

^{Development cycle.}

In a usability test, a user is given a typical task, such as:

• Create a user account.
• Retrieve a lost password.
• Change the current credit card information.
• Delete a user account.
• Find an article in the archive.
• Edit a posting made in a forum.
• Start a game with three players.

While the user is busy with the task, her actions towards completing the task are being recorded. These actions are then translated into performance metrics. Performance metrics depend on the task, it could be the number of clicks required to complete the task, the time taken or the number of wrongly clicked elements.

Usability testers should be a mix of target audience and average web users; 2-3 testers per iteration tend to be sufficient.

A typical usability setup has the following roles:

• The participant (our tester) sits in front of the device (laptop, mobile phone, tablet).
• The facilitator sits next to her and guides her through the test.
• The observers (developers of the app, managers, etc.) watch the usability test and discuss the tester’s performance (and how to improve it) afterwards.

The result of a usability test are a set of issues. Each of those issues should be assigned a priority (low, medium, high) and the next iteration of the development should focus on the high priority problems. No new issues should be added to the list until the most severe issues are fixed.

Performance metrics

Once web applications become complex, besides general usability we also need to consider various performance metrics, ideally metrics that are user-centric. A basic question to ask is: how long does it take for the entire application to load? This is of course a rather crude metric and it is not always clear what exactly this means, due to polling, etc. We thus need more fine-grained performance metrics. Google’s web.dev resource provides a good overview of what questions to ask in order to measure aspects of an application’s performance that are relevant to the user. Let’s focus on the three metrics that Google considers to be core web vitals:

• Largest contentful paint (LCP): LCP measures the time it takes to load a page’s main content, which correlates very well with users’ perceived load speed.
• First input delay (FID): FID measures the time between a user first interacting with a page and the browser processing corresponding event handlers.
• Cumulative layout shift (CLS): CLS measures a page’s visual stability by aggregating to what extent visible elements shift in the layout unexpectedly.

As an example of a popular online web metrics tool let’s take a look at Google’s https://web.dev/measure/. How does TU Delft’s homepage do in terms of its web performance? Let’s find out:

^{Screenshot taken September 2, 2020.}

Overall, it could be better. A click on View Report shows not only more performance metrics but also actionable insights (e.g. remove unused JavaScript, reduce initial server response time, avoid excessive DPOM size, …).

An alternative service is webhint.io (originally coming out of the Microsoft Edge development team). Once more, let’s use the TU Delft home page as an example:

^{Screenshot taken September 2, 2020.}

In both examples, we see that web performance only delivers part of the picture. There are many more metrics beyond those related to an application’s performance that we consider in this lecture. Other important types of web metrics revolve around accessibility and security.

HTML5

HTML5 is a set of related technologies (core HTML5, CSS, JavaScript) that together enable rich web content:

• Core HTML5: mark up content;
• CSS: control the appearance of marked-up content;
• client-side JavaScript: manipulate the contents of HTML documents and respond to user interactions.

Modern web application development requires knowledge of all three technologies. In practice, it also requires a whole set of additional frameworks and tools to go from prototype code to production code, such as build tools, transpilers, code coverage tools and so on. This is the case even “just” for frontend coding. We will introduce a few of those tools throughout the practical assignments.

Before HTML5 we had XHTML and HTML 4.01. XHTML is a reformulation of HTML 4 as an XML 1.0 application and stands for Extensible HyperText Markup Language. It looks as follows (taken straight from the W3C XHTML recommendation):

1
2
3
4
5
6
7
8
9
10

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>Virtual Library</title>
  </head>
  <body>
    <p>Moved to <a href="http://example.org/">example.org</a>.</p>
  </body>
</html>

XHTML was designed to make processing of web pages easier for machines by having a very strict set of rules. The problem though was that (X)HTML is written by developers, not machines and it turned out to be too much hassle to write valid XHTML. Moreover, browsers were and are able to render invalid XHTML pages properly (so why even try to write valid XHTML?) and thus XHTML was eventually abandoned in favor of HTML5, which is not only less strict but also added a host of new features to the language.

With this introduction of new features browser compatibility issues returned: some browser vendors are faster than others in implementing W3C standards (in addition to implementing their own non-standardized features). A good resource to check which browser versions support which HTML5 feature and to what extent is https://caniuse.com/.

As a concrete example, here is the browser support overview of HTML5 form features as provided by caniuse in 2021:

^{Screenshot taken on November 10, 2021.}

We can thus easily find out which browser versions do (not) support these features or only partially support them. This enables application developers to make choices—depending on their target population (and the most popular browsers among the target population), certain HTML5 features should be employed with care. That does not mean to not use the latest HTML5 features, it just means that we need to be considerate of our users and provide them with options, even if they rely on browsers that are not supporting the features we use. As an example, let’s use the <input type="date"> widget. Here is how the MDN demo on this input type is rendered on Firefox and Safari respectively :

^{Firefox screenshot taken September 2, 2020.}

^{Safari screenshot taken September 2, 2020.}

We find that Firefox supports this input type with a calendar picker widget, while Safari does not. What can we do in this case? The answer is to use (or create!) polyfills. A polyfill is a code snippet that brings a modern browser feature (such as a calendar picker) to browsers that do not natively support that feature. Here is an example of a polyfill for Safari (among others). Sometimes when looking for polyfills one can also come across the term shim. These concepts are not quite interchangeable, though they often used in the same contexts.

The move towards HTML5

The initial list of HTML tags (1991/92) was static: <title> <a> <isindex> <plaintext> <listing> <p> <h1> <address> <hp1> <dl> <dt> <ul>. JavaScript was created within 10 days (which explains many JavaScript quirks) in May 1995 by Brendan Eich, a co-founder of Mozilla who today is behind the browser Brave. At the time, Eich worked at Netscape, which offered Netscape Navigator, a dominant browser in those years. It was the beginning of client-side dynamic scripting for the browser.

Plugins were created to go beyond what at the time was possible with HTML. Probably the most famous plugin remains Adobe Flash, which was introduced in 1996. HTML5 is a drive to return rich content directly into the browser, without the need for plugins or addons.

HTML5 introduced a number of semantic HTML elements including <article> <footer> <header> <main> <aside> <section> <output>. As a guideline, when creating an HTML document, it is always best to select the most specific element to represent your content (instead of only using <div>’s). Semantic elements provide meaning but do not force a particular presentation. Older HTML elements (pre-HTML5) often do force a particular presentation, e.g. <b> (bold) or <i> (italics). At the same time, those heavily used HTML elements cannot be moved to an obsolete state - as this would inevitably break a large portion of the web. For the browser vendors, backwards compatibility is a necessity, not an option. It should be pointed out that semantic HTML is quite different from the grand vision of the Semantic Web :

1
2
3

The Semantic Web is a Web of data — of dates and titles and part 
numbers and chemical properties and any other data one might 
conceive of.

Self-check

Here are a few questions you should be able to answer after having followed the lecture and having worked through the required readings: