# On the Design of Notations

ME

ME

= Maine

## Postal codes

Looking at GA= Georgia, and FL= Florida, it appears that there is no real rule.

## Postal codes

Looking at GA= Georgia, and FL= Florida, it appears that there is no real rule.

• The first letter of the code is the first letter of the state.
• If the state name is two words, then second letter of code is first letter of second word (e.g. NY = New York)
• Otherwise, the second letter is an apparently random choice out of the other letters of the state name.

### Codes

It's Nebraska, but NB (or NR, NR, NS, NK) would have been better

### Codes

It's Nebraska, but NB (or NR, NR, NS, NK) would have been better

MI: Mississippi, Missouri, Michigan, or Minnesota?

### Codes

It's Nebraska, but NB (or NR, NR, NS, NK) would have been better

MI: Mississippi, Missouri, Michigan, or Minnesota?

It's Michigan, but MG would have been a better choice

### Codes

It's Nebraska, but NB (or NR, NR, NS, NK) would have been better

MI: Mississippi, Missouri, Michigan, or Minnesota?

It's Michigan, but MG would have been a better choice

MS: Mississippi, Missouri, or Minnesota?

### Codes

It's Nebraska, but NB (or NR, NR, NS, NK) would have been better

MI: Mississippi, Missouri, Michigan, or Minnesota?

It's Michigan, but MG would have been a better choice

MS: Mississippi, Missouri, or Minnesota?

It's Mississippi, but MP would have been a better choice.

### Active and Passive

But solving these problems with reading 2-letter codes would still not solve the problem of writing them: your passive and active abilities are different.

### Doing it better

I couldn't believe it wasn't possible to do the 2-letter codes better.

So I wrote a program (in ABC as it happens; more on that later).

The best rule I came up with:

• For single-word state names, use the 1st and 4th letter, except:
• For the 4 states with a double letter in the first 4 letters (Minnesota, Mississippi, Missouri, Illinois) use the 1st and 5th letter.

### The point

This is about the original design: Canadian territories were later integrated into the system.

But that doesn't invalidate the argument: the 2-letter codes were introduced because of automation, but that is no excuse for ignoring the needs of people.

(Recommendation: How The States Got Their Abbreviations)

### Usability

Usability is about designing things (software/programming languages/cookers) to allow people to do their work:

• Faster
• With less errors
• Whilst enjoying it

Efficient, Error-free, Enjoyable or
Fast, Faultless and Fun

### HCI

A problem is that the people designing things are usually not the people who will be using those things, and yet they tend to design for themselves.

So... you have to use HCI techniques:

• design for the user, not for yourself or the computer
• user test
• design iteratively.

### Notations

Few talk about the usability of notations.

Yet the design of notations affects what you can do with them.

## Numbers

For instance, Roman numerals:

• OK for representing numbers: CXXVIII

CXXVIII+CXXVIII
=CCXXXXVVIIIIII
=CCXXXXVVVI
=CCXXXXXVI
=CCLVI

• Terrible for multiplication (which was a university subject until the introduction of Arabic numerals after the renaissance)
• Disastrous for division.

### Homework

I was helping my children with their maths homework, and a question arose for me:

Why do they make things so difficult?

My conclusion was that the problem is mathematics is taught in a historical order, and there has never been a synthesis.

So I went back to first principles with the question:

What would mathematical notation look like if it were designed with consistency and usability in mind?

### Warning

What follows was more than a year's work, using reams of paper. It is hard work making things simple.

When you achieve a final simple result, it often looks so obvious that it hard to appreciate how difficult it was to get there.

As a colleague who designs program interfaces remarked: "When you succeed in making an interface as easy to use as a coffee machine, they treat you like a plumber"

I'm only going to show you the tip of the iceberg here.

It resulted in a monograph that I wrote for my sons' birthdays. You can read it here: Numbers.

### Declarative

Before I show the details, let me remind you of the difference between procedural and declarative approaches.

### Procedural vs declarative

Procedural approaches describe the how.

Declarative approaches describe the what.

In school you learn procedurally how to add, subtract, multiply and divide, and then you are told

The square root of a number is another number that when you multiply it by itself, gives you the original number.
• Simple
• short
• obvious
• understandable.

This doesn't tell you how to calculate the square root; but no problem, because we have machines to do that for us.

### Procedural code

```function f a: {
x ← a
x' ← (a + 1) ÷ 2
epsilon ← 1.19209290e-07
while abs(x − x') > epsilon × x: {
x ← x'
x' ← ((a ÷ x') + x') ÷ 2
}
return x'
}```
• What does it do? Under what conditions?
• How does it do it? What is the theory behind it?
• Is it correct? Can I prove it?
• Under what conditions may I replace it, or a part of it with something else?

This is why documentation is so essential in procedural programming, because the distance between the description of the problem space and the code is so great.

### Mathematical Notation

a+b

You can define subtraction as

(a+b) − b = a

This is a declarative definition. It tells you the what but not the how.

There is also a monadic version of −, which can be defined as:

−a = 0−a

Where 0 is the identity for addition, since

a+0 = a

### Multiplication

Multiplication is at its heart repeated addition:

a × 3 = a + a + a

(Actual declarative definition:

a×(b+c) = a×b + a×c

)

It also has an identity value:

a×1 = a

Its complement is division, defined in the same way as subtraction:

(a×b) ÷ b = a

(I use ÷ instead of / because when user-testing with my target audience, they said "Please use the same symbols as on a calculator")

Notably, there is no monadic version of divide. But if we define it using the same pattern:

÷a = 1 ÷ a

something surprising happens: identities that we know from the lower level have exactly the same form as ones at this higher level. For instance:

−−a = a
÷÷a = a

a−−b = a + b
a÷÷b = a × b

### Identities

−(a−b) = b−a
÷(a÷b) = b÷a

(Note that although − and ÷ are not commutative, they are therefore commutable.)

### Up another level

Just as multiplication is repeated addition, raising to the power is repeated multiplication:

a×3 = a + a + a
a↑3 = a × a × a

So we can define its complement in the same way:

(a↑b)↓b = a

This is of course what we know of as root, where x↓y traditionally, and weirdly, is notated

y√x

So if ↑ is a higher version of multiplication, then ↓ is just a higher version of division.

### The point

Defining it in this way suddenly exposes literally dozens of well known identities that have a similar form to identities at the two lower levels!

Just to pick a couple out:

a×(−b) = −(a×b)

a×(−b) = −(a×b)
a↑(−b) =  ÷(a↑b)

### Identities 1

a×(−b) = −(a×b)
a↑(−b) =  ÷(a↑b)

(a−b = 1/ab)

a×(÷b) = a÷b

### Identities 2

a×(÷b) = a÷b
a↑(÷b) = a↓b

(I consider this so beautiful, that even if this had been the only result, the whole exercise would have been worth it!)

### Identities 2

a×(÷b) = a÷b
a↑(÷b) = a↓b

(a1/b = b√a)

### Commutative

Since + and × are commutative

a+b = b+a
a×b = b×a

you can extract both a and b from an expression:

(a×b)÷b = a
(a×b)÷a =
(b×a)÷a = b

But ↑ is not commutative (nor commutable)

a↑b ≠ b↑a

So we need another operator to get b.

### The other complement of power

(a↑b)↓b = a
(a↑b)⇓a = b

This is logarithm, where x⇓y is equally weirdly notated traditionally as

logy x

This exposes yet more interesting identities, of which I will show only one.

÷(a÷b)  = b÷a

÷(a÷b)  = b÷a
÷(a⇓b)  = b⇓a

### Identities 3

÷(a÷b)  = b÷a
÷(a⇓b)  = b⇓a

(1/ logba = logab)

(I may have learned this at school, but if I did, I had forgotten it. When I saw this result, I was so amazed, that even though I could prove it, I have to admit I checked it with some values as well, to make sure it was right).

• Consistent
• Easier to use (once you've learnt it)
• Exposes otherwise hidden relationships, such as the close relationship between log and root.
• Use the same methods for solving equations:

a+2 = 4
a = 4−2

a × 2 = 4
a = 4 ÷ 2

a↑2 = 4
a = 4↓2

2↑a = 4
a = 4⇓2

### There's more

There's much more, but you'll just have to read the monograph

## The Web

2023 — 32nd anniversary of the World Wide Web being announced:

6 August 1991: Tim Berners-Lee posts a short summary of the World Wide Web project to an internet newsgroup inviting collaborators

The first web servers had been made publicly available a few months earlier [Pemberton: The 100 year Web] .

### Background

The web had been made possible by the internet becoming open and international:

The first open internet node outside of North America was installed at the CWI in Amsterdam, the Netherlands in November 1988 [CWI]. Two spin-offs were created to extend the internet into the rest of Europe.

On that day in 1988, public computing itself was barely thirty years old: in 1957 a computer had been installed for the first time in a municipality, as it happens in Norwich, UK [Norwich].

### Properties

The original web was not revolutionary: hypertext programs that could do similar things already existed.

But the web had the right mix of existing elements:

• a hypertext foundation
• connected to the internet
• with a simple and easy-to-implement protocol similar to FTP
• separating document formats from delivery methods
• using an existing markup methodology (SGML) that was easy to understand and use, even for non-technical people
• allowing the combination of existing internet protocols and formats so that people could leverage existing online content for their first web site,

and possibly the most important one:

A major property was that it was based on declarative principles.

### Declarative markup: HTML

Although there were some mistakes, HTML largely specified the role of the elements, rather than how they should appear.

For instance, an `h1` was a top-level heading with no a priori requirement that it be displayed in any particular way, larger or in bold. It just stated its purpose.

This has a number of advantages, including machine and modality independence: you can just as easily 'display' such a document with a voice-reader as on a screen, without having to use heuristics to guess what is intended.

### <a>

The poster-child of HTML declarative markup is the `<a>` element:

`<a href="talk.html" title="…" target="…" class="…">My Talk</a>`

This single line compactly encapsulates a lot of behaviour including

• what the link looks like
• what to do when you hover over the link
• activating the link in several ways
• what to do with the result
• hooks for presentation changes.

Doing this procedurally in program code would be a lot of work.

### Mistakes

Mistakes included `hr` (horizontal rule), and elements like `b` and `i` for bold and italic, which specify a visual property rather than a purpose.

But most of the structure was purely declarative.

### Implementers

The original HTML surprisingly did not have facilities for embedding images into documents, so they were added by the implementers of the first really successful browser, Mosaic.

Unfortunately, they didn't do a great job. They added a single element `<img src="…">` to embed an image at that location in the code.

This has two regrettable, related, disadvantages: firstly, there is no failure fallback, and secondly there is no alternative for non-visual environments.

### Fallback

A better design would have allowed the element to have content to be used in fallback cases. For instance

```<img src="cat.png">
<img src="cat.jpg">
A <em>cat</em>, sitting on a mat.
</img>
</img>```

If the outer `img` should fail for whatever reason (the resource unavailable, the browser not supporting `png` images, or it being a non-visual browser), the nested `img` would be tried, and if that failed, the text would be used.

The advantage of such a design to visually impaired users of the web should be obvious.

When `png` images were introduced on the web, their usage was held back for a long time because of the lack of such a mechanism: people had to wait until a critical mass of browsers were available that could display the new image type before they could start using them.

This created the conditions for a potential vicious circle of png not being used because there were no implementations, and not being implemented because there were no users.

### More mistakes

Then there are the unfortunate `blink` and `font` elements that were introduced by the implementers, and we should not let that excrescence the `frameset`, with its security and usability problems, go unmentioned either.

### The URL

A major innovation of ther web was the URL, which allowed you to combine documents from a plethora of sources into a single web page.

The URL is an ultimate example of a declarative interface, specifying what you want, and not step-wise how to get it.

Coding a URL as program code is truly a lot of work.

Analysing the design of the URL would require a complete 45 minute talk in itself, so let me point you instead to: Pemberton: On the design of the URL

### https

The https scheme is a mistake, one of a number of early mistakes introduced by Mosaic/Netscape, like `<blink>`, `<img>`, and `<frameset>`.

The two URLs

` http://www.example.com/doc.htmlhttps://www.example.com/doc.html`

locate the same resource in every way. The only difference is in details of the protocol being used to retrieve the resource.

Whether the connection is encrypted or not should be part of the protocol negotiation; users shouldn't have to be confronted with the negotiation between the machines about how they are going to transport the data.

Now we are being forced to change all our documents to use `https` links. That shouldn't have been necessary.

### Stylesheets: CSS

Another advantage of declarative markup is that since display properties are not baked in to the language you can use style sheets to control the display properties of a document, without altering the document itself.

In fact one of the first activities of the newly-created W3C was to add style-sheets as quickly as possible to undo the damage being done by the browser manufacturers, who were unilaterally adding visually-oriented elements to HTML, such as `font`, and `blink`.

The result, CSS, is another example of a successful declarative approach [CSS].

### CSS

When W3C started the CSS activity, Netscape, at the time the leading browser, declined to join, saying that they had a better solution, JSSS, based on Javascript – in other words a procedural rather than declarative approach. Instead of the declarative CSS

`h1 { font-size: 20pt }`

you would use script to say

`document.tags.H1.fontSize = "20pt";`

The entry on Wikipedia remarks:

"JSSS lacked the various CSS selector features, supporting only simple tag name, class and id selectors. On the other hand, since it is written using a complete programming language, stylesheets can include highly complex dynamic calculations and conditional processing." [JSSS]

### Analysis

The first version of CSS was produced quickly, and has proved to be durable.

CSS is a greatly underappreciated resource. It is surprising how much can be done in a declarative manner, where many resort to using javascript.

I highly recommend You don't need Javascript for that for examples.

That notwithstanding, there were some initial design faults.

### Design faults: streaming

A design requirement was that CSS should stream. So any selector that couldn't support streaming was excluded. This is why the selectors are not symmetric, for instance you can select the following sibling, but not the preceding one.

Furthermore, a basic selector is the 'descendent of', which is very expensive: some environments even recommend against its use. 'Child of' would have been a more useful basic selector, with 'descendent of' an advanced selector.

The streaming decision I believe was an error: the more so since CSS selectors are now being used for other purposes than streaming. It would have been better to design a symmetric set, and indicate which were safe for streaming.

### Design faults: selectors

Another error was the ad hoc nature of the selector design: if a new selector was needed, they would look at the available characters left for its representation.

Compare this with XPath selectors, that started off with a coherent design first.

### Design faults: grid

The first version of CSS was designed by people from print environments, and not designers. Consequently they failed to understand how important a grid was.

Luckily this has been corrected now, but it took far too long for such an essential design element.

The lack of designers initially also accounts for the appalling colour specification mechanisms.

RDF is the underpinning for the Semantic Web.

The original design of RDF made the mistake of conflating the abstraction with its representation, and produced an XML definition of RDF.

Later, other serialisations emerged, making it clear that RDF is an abstraction, independent of representations.

RDFa is one such alternative notation, layered on top of HTML, XHTML, and XML, that uses attributes to allow the extraction of RDF from documents.

You can add metadata to an HTML document by adding `<meta>` and `<link>` elements in the head.

`<meta name="description" content="A site about fish" />`

gives a description of the current document. You could say that the current page has a `description` property, whose value is "```A site about fish```".

Similarly you can say:

`<link rel="next" href="thecod.html" />`

which says that if you consider this page as one in a series of pages, the next one is `thecod.html`. In other words, this page has a `next` relation to `thecod.html`.

There are a smattering of other places in HTML where you can add some metadata, such as the `title` element and attribute in places, and the `cite` attribute on `<blockquote>` and others, but that is about it.

### Mistake

In passing, you might wonder why you can't say

`<meta name="description">A site about fish</meta>`

and the answer is simply that at the time this feature was added to HTML, some browsers would incorrectly have displayed the text in the `meta` element, even though it was in the `<head>` and so to prevent that happening the content was put in an attribute instead.

This was a mistake. They should have provided both and allowed the browsers to catch up.

### RDFa

RDFa generalises the meta and link elements to allow any element to generate metadata about the document. For instance

``` <h1 property="dc:title">Fish of the World</h1>
<p>by <span property="dc:creator">John Smith</span></p>```

and

```<link about="[_:StevenPemberton]"
rev="foaf:img" type="image/jpg"
href="Steven.Pemberton.jpg" />
rel="foaf:primaryTopicOf"
href="" />
<h1><a href="photos.html"
property="foaf:name">Steven Pemberton</a>
</h1>```

### XML

The original HTML was based on SGML, which is fairly complex and hard to implement.

As a result, XML, a pure subset of SGML, was created.

It was a good design, and they were brave to keep it to a subset.

For an analysis see: Pemberton: On the representation of abstractions

## Keynote, 2004

"Parsing is quite easy

It would be fairly easy to add a generalised part to the XML pipeline that parsed unmarked-up text, and produced XML as a parse tree: it's just a different sort of transform.

We could have our cake and eat it!"

## Invisible XML

Data is an abstraction: there is no essential difference between the JSON

`{"temperature": {"scale": "C"; "value": 21}}`

and an equivalent XML

`<temperature scale="C" value="21"/>`

or

```<temperature>
<scale>C</scale>
<value>21</value>
</temperature>```

or indeed

`Temperature: 21°C`

since the underlying abstractions being represented are the same.

### Representations

We choose which representations of our data to use, JSON, CSV, XML, or whatever, depending on habit, convenience, or the context we want to use that data in.

On the other hand, having an interoperable generic toolchain such as that provided by XML to process data is of immense value.

How do we resolve the conflicting requirements of convenience, habit, and context, and still enable a generic toolchain?

### ixml

Invisible XML (ixml) is a method for treating non-XML documents as if they were XML, enabling authors to write documents and data in a format they prefer while providing XML for processes that are more effective with XML content.

ixml lets you treat any parsable format as if it were XML, without the need for markup.

### Example converting CSS

`body {color: blue; font-weight: bold}`

can be converted into XML like these two, depending on choice:

```<css>
<rule>
<simple-selector name="body"/>
<block>
<property>
<name>color</name>
<value>blue</value>
</property>
<property>
<name>font-weight</name>
<value>bold</value>
</property>
</block>
</rule>
</css>```
```<css>
<rule>
<selector>body</selector>
<block>
<property name="color" value="blue"/>
<property name="font-weight" value="bold"/>
</block>
</rule>
</css>```

### Quick example

You have one or more documents in a non-XML format. You supply a description of that format, that includes how it should be converted to XML. The ixml processor then reads the description, and uses that to read and convert the documents to XML.

As a simple example, you want to convert a date to XML:

`4 November 2021`

So we describe what a date looks like:

`date: day, " ", month, " ", year.`

### Quick example

A day is one or two digits:

`day: digit, digit?.digit: ["0"-"9"].`

Define a month:

```month: "January"; "February"; "March"; "April";
"May"; "June"; "July"; "August";
"September"; "October"; "November"; "December".```

A semicolon can be read as "or": it allows you to specify alternatives for a rule definition.

Finally a year is just four digits:

`year: digit, digit, digit, digit.`

### Quick example

Running it on the input "4 November 2021" gives:

```<date>
<day>
<digit>4</digit>
</day>
<month>November</month>
<year>
<digit>2</digit>
<digit>0</digit>
<digit>2</digit>
<digit>1</digit>
</year>
</date>```

But we're really not interested in the `digit` elements. To indicate that, we just put a minus sign before the rule for digit:

`-digit: ["0"-"9"].`

which says this element should not be produced (we still get the element content though), giving:

```<date>
<day>4</day>
<month>November</month>
<year>2021</year>
</date>```

### ixml in ixml

Unsurprisingly ixml is also expressed in ixml.

For instance a `rule` is

`rule: (mark, s)?, name, s, ["=:"], s, -alts, ".".`

More details at Introduction to Invisible XML which has links to a number of design papers, tutorials, and a link to the specification.

## Programmers are possibly human too

Imagine, hypothetically, that programmers are humans...despite all evidence to the contrary:

## Programmers are possibly human too

Imagine, hypothetically, that programmers are humans...despite all evidence to the contrary:

• They work at night, and sleep during the day

## Programmers are possibly human too

Imagine, hypothetically, that programmers are humans...despite all evidence to the contrary:

• They work at night, and sleep during the day
• They only need 2 hours of sleep

## Programmers are possibly human too

Imagine, hypothetically, that programmers are humans...despite all evidence to the contrary:

• They work at night, and sleep during the day
• They only need 2 hours of sleep
• They survive on a diet of pure caffeine and sugar

## Programmers are possibly human too

Imagine, hypothetically, that programmers are humans...despite all evidence to the contrary:

• They work at night, and sleep during the day
• They only need 2 hours of sleep
• They survive on a diet of pure caffeine and sugar
• Many actually enjoy using the vi editor

## Programmers are possibly human too

Imagine, hypothetically, that programmers are humans...despite all evidence to the contrary:

• They work at night, and sleep during the day
• They only need 2 hours of sleep
• They survive on a diet of pure caffeine and sugar
• Many actually enjoy using the vi editor

Also pretend, just for a moment, that their chief method of communicating with a computer was with programming languages.

## Programmers are possibly human too

Imagine, hypothetically, that programmers are humans...despite all evidence to the contrary:

• They work at night, and sleep during the day
• They only need 2 hours of sleep
• They survive on a diet of pure caffeine and sugar
• Many actually enjoy using the vi editor

Also pretend, just for a moment, that their chief method of communicating with a computer was with programming languages.

What should you do?

### ABC

We designed a programming language: ABC

We used HCI principles:

• designed for the user
• user tested
• designed iteratively.

### ABC: results

A procedural language with only 5 very high-level data types.

Our biggest take aways:

• Most languages provide low-level tools for programmers to build high-level tools: but it's the high-level tools they need. So supply those as primitives; they can be used for low-level needs if necessary.
• Programs are mostly about sorting and searching: these should be primitives in the language
• Even though an interpreted language, it often out-performed compiled languages, because of the high-level primitives.

• Efficient:
• Error-free:
• Enjoyable:

### ABC: results

• Efficient: people programmed about 10 times faster in ABC than languages like C and Pascal.
• Error-free:
• Enjoyable:

### ABC: results

• Efficient: people programmed about 10 times faster in ABC than languages like C and Pascal.
• Error-free: the number of bugs is not linear with the size of a program, but O(L1.5). ABC programs were about 25% the size of equivalent programs, predicting an 8 fold reduction in bugs.
• Enjoyable:

### ABC: results

• Efficient: people programmed about 10 times faster in ABC than languages like C and Pascal.
• Error-free: the number of bugs is not linear with the size of a program, but O(L1.5). ABC programs were about 25% the size of equivalent programs, predicting an 8 fold reduction in bugs.
• Enjoyable: At least one user was delighted - he had tried several times to learn programming before, but had failed, but with ABC his first program already helped him in his research.

### ABC: results

• Efficient: people programmed about 10 times faster in ABC than languages like C and Pascal.
• Error-free: the number of bugs is not linear with the size of a program, but O(L1.5). ABC programs were about 25% the size of equivalent programs, predicting an 8 fold reduction in bugs.
• Enjoyable: At least one user was delighted - he had tried several times to learn programming before, but had failed, but with ABC his first program already helped him in his research.

Many cryptographic algorithms in use today were designed with ABC.

ABC went on to form the basis of Python.

### TAXATA

In building a programming environment for ABC, we developed a concept that was a stronger version of WYSIWYG, that we called TAXATA: Things are exactly as they appear

We built a system (Views) that made this principle the central element of the design: if you changed something (edited it) the system changed itself to match.

### Views

This system had an extensible markup language, vector graphics, style sheets, a DOM, client-side scripting ... today you would call it a browser (it didn't use TCP/IP though).

It ran on an Atari ST (amongst others).

## Declarative programming

The Views system client-side programming language was a first attempt at defining a declarative programming language.

We saw that it gave you immense power, and ease of use at the same time.

But that is for next time...

## Conclusion

Notations are a greatly overlooked issue in the field of usability.

Good notations have all the features of good interaction designs:

• Efficiency in use
• Reducing errors
• More enjoyable to use

## Thank you!

And see you in person in April!