You can measure the performance of your website in the milliseconds it takes to handle a request, or how many requests per second. But this talk is about subjective speed: how fast does it feel? The contents of the page come to us at the speed of light. But it has to show up on the screen, and then your brain needs to process it.

And when you do an online payment, it may be irritating when it is slow, but even worse when you just end up on a homepage without indication of success or failure.

Perceived performance is dependent on the actual performance, the UX (user experience), and the expectec performance.

If your brain is active, time seems to move faster. If a page takes less than a second to load, do you really need a spinner or progress bar? The Polar app at some point changed to show a spinner for every action. Nothing changed in the speed, but reviews dropped: it reminded you that you had to wait all the time.

So instead, you may be able to distract the user. The user needs time to focus. So don't show a blank page, but show a skeleton page, which has roughly the structure of the page. Then the user already has a chance to see where the focus should be. I hope Plone will do this.

Show a spinner for ten seconds: slow. Show a simple animation for ten seconds: you don't notice that it is just as slow.

The perception of performance is often just as important as actual performance.

Collections are hard to explain in user trainings. In most cases you have to explain default pages first. Can we make this simpler? In Volto we do this by having folderish pages.

What if we kill all content types, and rely on one content type to rule them all? Confession: I actually voted against folderish pages in the Framework Team twice. So I was sceptical. With Volto we thought, let's give it a try, and we got overwhelmingly positive feedback. It avoids cognitive overhead.

Same with the Save button. Pastanaga puts this in the top left corner of the page, and I hated it. Then I actually tried it for 30 seconds and loved it.

Composite pages. The idea has been around for ages, and there have been lots of add-ons that do this, but it was never really good enough for core. Always a problem for migration.

Naming things. Some names are open for discussion. We renamed tiles to blocks. We renamed proxy to teaser. Topics, Smart Folders, Collections: in Volto we simply call this Listings.

I rediscovered a blog by Alexander Limi, one of the original creators of Plone: https://limi.net/things-plone Still an interesting list after all these years. And I recognize parts in the Pastanaga UI.

Plone in 2019 is tiny. This means we cannot afford to reinvent the wheel over and over again. So Volto builds on React, which has far more contributors. We tried Angular and Vue too, but React seems the best system. And we use the standard stack with React, Redux, Semantic UI. This will be very familiar to most React developers.

We have trained people with zero experience in html and css, and in three days they could basically theme a Plone Site, even though we only started talking about Plone and Volto in the last two hours of the last day. It was really amazing.

With Plone 6 we aim to simplify the stack. There are several PLIPs (PLone Improvement Proposals), like having the Plone Site root be a dexterity item. Most of these are optional, they would be nice to have for cleaning things up, but they are not strictly necessary. You can use "Plone 6" today:

• Plone 5.2
• Python 3
• Volto 4

Carrot and stick: selling a Plone upgrade just because you get Python 3, and not the unsupported Python 2 (stick), may not be enough to convince your customer. As extra carrot you can say: you can have Volto.

You can try Volto out live: https://volto.kitconcept.com (Still Volto 3 at this point.) This weekend, come join the code sprint at the conference.

The upgrade-step:directory ZCML directive allows us to use a new upgrade step definition syntax. Less room for typos. Upgrades in the given directory are auto-discovered. Each directory is a generic setup upgrade profile. You no longer need a profile version in metadata.xml.

With the bin/upgrade command you can upgrade your Plone site, install an add-on, upgrade an add-on. This includes progress logging, so you see that something happens during long upgrade steps.

Why do we write upgrades? We want to consistently alter content and configuration. Prevent undocumented changes through the Plone UI: your policy package should have the needed configuration, without relying on manual changes done on the live site. We want to apply a minimal set of changes, instead of reinstalling an add-on.

We have several helpers methods, for example for:

• class migration and in-place migration
• rebuild, add, remove indexes
• update object or workflow security

And there is much more, like deferrable upgrade steps, possible because we separately track which upgrade steps have been executed.

We are working on getting it running on Plone 5.2.

Code: https://github.com/4teamwork/ftw.upgrade

My first Plone conference was in Vienna. Glad to be here now.

Everything begins in ancient Babylonia. They had problems like measuring the size of fields after a flood. So they developed geometry (in Egypt too). They had to solve quadratic equations, like this:

a*x*x + b*x + c = 0

They used a different formula than what we are used to, because they had difficulty with the concept of negative numbers: you cannot have a field with a length of minus one meter.

This is basically software engineering, right?

Fast forward to the Renaissance. It is the year 1494, and Luca Pacioli publishes a book on mathematics. He said that the cubic equation (similar to the last, but raising to the third power) would probably never have a general solution. He was wrong. I show you a solution in Python, taken from Wikipedia.

Scipione dal Ferro found a solution a few years later. He seems to have come up with an algorithm to calculate it. Start with a formula, turn this into a series of instructions, and you have an algorithm.

Enter Gerolamo Cardano, Niccolo Tartaglia, and Lodovico Ferrari, all from the sixteenth century. Tartaglia also found a solution, shared it secretly with Cardano, who taught it to his student Ferrari. Cardano found the original solution from Dal Ferro, thought himself no longer sworn to secrecy, and eventually published the solution with Ferrari, together with a solution for the quadratic equation. Tartaglia (nickname for stutterer) became an enemy, and they fought mathematical battles, and we have some papers from this.

When you calculate with cubic roots, part of the solution uses the square root of minus one. At the time this was garbage. Currently we know this as an imaginary number. So it raised questions, which were finally answered two centuries later by Lagrange, Gauss, Ruffini, and Abel, between 1770 and 1826.

Why did this take so long? They lacked the abstractions needed to move forward. Babylonians did not know how to deal with negative numbers. Dal Ferro and company did not know how to deal with imaginary or complex numbers.

Moving forward. Is there a field where the lack of abstractions is preventing progress. I think yes, and it is called software engineering.

• How do we specify what a software should and should not do?
• How do we validate the behavior of code we write?
• How do we describe our architectures?

The answer is currently text: sentences, diagrams, graphs.

The history of the discovery of the mathematical solutions was a tale to tell that in science, progress usually stalls until we are able to go from one language to another. In software, of course there are new programming languages, but I don't mean that.

The Agile Manifesto tells fruitful and interesting things, and gives important results. But it does not improve how we do the software thing.

Software has built a different world, just for example the internet. It should also be a better world. Privacy is going down, are we building a police world, without intending to?

We need a quest to find a better theory of software.