# Active Essays on the Web

>This property has a great benefit: when combined
with a written essay, it allows the reader to see an animated
and interactive expression of what is being taught.

>An “Active Essay” is a written essay mixed with a com-
puter program. The term was coined by Alan Kay.

- Literate Programming (think `R Markdown`, `Notebooks`,...)

>A background can be seen as a special version of macro
or template. A macro is a technique to share a common
structure in documents. It is useful to reduce redundancy
and to improve maintainability. However, it is easy to make
a macro be too complicated by including another macro in
it. The background is a better compromise for the end-user.

>Sometimes the entire state of an object does not need to
be save. For example, when text is saved during editing,
should the position of the cursor should be saved or not?
There are two strategies. One is to save everything with
a few things excepted (deep copy), and the other is to save
only the specified object types. Tinlizzie WysiWiki took the
latter course, although Tweak’s native mechanisms were the
former

>An author often writes example source code in-
side the workspace, so that a user can try the actual func-
tions while reading the text. A REPL is a two-way dialog
between machine and human, while a workspace is a three
way conversation among machine, author, and user.

- **Versioning**

# Explorable Explanations

>Most interactive widgets dump the user in a sandbox and say "figure it out for yourself". Those are not explanations. To me, an essential aspect of the "explorable explanation" concept is that the author holds up his end of the conversation. The author must guide the reader, and provide a structure for the learning experience. Only then can the reader respond, by asking and answering the questions that the author provokes.

- [http://worrydream.com/TenBrighterIdeas/](http://worrydream.com/TenBrighterIdeas/) shows that controls with immediate feedback are nice (e.g. `drag`)

# [Polygons](https://ncase.me/polygons/)
- stuff can break if the user wants to
- give feedback as fast as possible (face changes before polygon is dropped)

# Take Away

## End Users
- important that interaction and explanation are interconnected
- show how I can change things, and where the effect happens
- give ordering for controls, do not just throw 100 buttons at me
- too much freedom is bad
- there is a limited number of controls that make sense
- interactive parts clearly highlighted and should be intuitive how to use
- slowly introduce me to the tools
- use the same tools over and over not every time a new tool

## Programmer
- we cannot expect the user to use the controls in the intended way, *need to handle global state?*
- consequences the user does need to be tracked (i.e. cause and effect have to be modeled and kept)
- what caused what, how can we reverse what
- there is only a limited number of controls that are useful - probably make them as some kind of component
- limit controls -> less stuff can break + easier for user
- create tool, so interactive websites are as easy to create as static ones


# General Thoughts about the Domain
- collaborative work needs some kind of merging
- Designers create Objects/Mock-Ups of Objects
- Objects could have an internal description (that should be hidden in a production environment) as well as their corresponding code
- show which code influences which object at which time?