lots more writing

23 files changed, 278 insertions, 120 deletions

diff --git a/root/articles/mmmfs/$order b/root/articles/mmmfs/$order
index 6707527..dd9746b 100644
--- a/root/articles/mmmfs/$order
+++ b/root/articles/mmmfs/$order
@@ -1,8 +1,10 @@
 abstract
-problem-statement
+motivation
+historical-approaches
 framework
 mmmfs
 examples
 evaluation
+conclusion
 references
 ba_log
diff --git a/root/articles/mmmfs/abstract/text$markdown+sidenotes.md b/root/articles/mmmfs/abstract/text$markdown+sidenotes.md
index e69de29..9ac0894 100644
--- a/root/articles/mmmfs/abstract/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/abstract/text$markdown+sidenotes.md
@@ -0,0 +1,4 @@
+abstract
+========
+
+[tbd]
diff --git a/root/articles/mmmfs/ba_log/print: text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/ba_log/print: text$moonscript -> fn -> mmm$dom.moon
new file mode 100644
index 0000000..83c0c2c
--- /dev/null
+++ b/root/articles/mmmfs/ba_log/print: text$moonscript -> fn -> mmm$dom.moon
@@ -0,0 +1,16 @@
+import div, section, h1, h2, hr from require 'mmm.dom'
+import link_to from (require 'mmm.mmmfs.util') require 'mmm.dom'
+import ropairs from require 'mmm.ordered'
+
+=>
+  div {
+    h1 link_to @, "appendix: project log"
+    table.unpack for post in *@children
+      continue if post\get 'hidden: bool'
+
+      section {
+        hr!
+        h2 link_to post, post\gett 'name: mmm/dom'
+        (post\gett 'mmm/dom')
+      }
+ }
diff --git a/root/articles/mmmfs/ba_log/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/ba_log/text$moonscript -> fn -> mmm$dom.moon
index 1dd0bc3..37ffc78 100644
--- a/root/articles/mmmfs/ba_log/text$moonscript -> fn -> mmm$dom.moon
+++ b/root/articles/mmmfs/ba_log/text$moonscript -> fn -> mmm$dom.moon
@@ -1,10 +1,10 @@
-import div, h3, ul, li from require 'mmm.dom'
+import div, h1, ul, li from require 'mmm.dom'
 import link_to from (require 'mmm.mmmfs.util') require 'mmm.dom'
 import ropairs from require 'mmm.ordered'
 
 =>
   div {
-    h3 link_to @
+    h1 link_to @, "appendix: project log"
     ul do
       posts = for post in *@children
         continue if post\get 'hidden: bool'
diff --git a/root/articles/mmmfs/conclusion/text$markdown+sidenotes.md b/root/articles/mmmfs/conclusion/text$markdown+sidenotes.md
new file mode 100644
index 0000000..de38bec
--- /dev/null
+++ b/root/articles/mmmfs/conclusion/text$markdown+sidenotes.md
@@ -0,0 +1,4 @@
+conclusion
+==========
+
+[tbd]
diff --git a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
index 773c842..812b0c5 100644
--- a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
@@ -2,6 +2,9 @@ evaluation
 ==========
 
 ## examples
+In this section I will take a look at the implementations of the example for the use cases outlined above,
+and evaluate them with regard to the framework derived in the corresponding section above.
+
 ### publishing and blogging
 Since mmmfs has grown out of the need for a versatile CMS for a personal publishing website, it is not surprising to
 to see that it is still up to that job. Nevertheless it is worth taking a look at its strengths and weaknesses in this
@@ -159,8 +162,8 @@ The content editor is wholly separate from the visible representation, and only
 fileder can be edited. This means that content cannot be edited in its context, which is particularily annoying
 due to the fragmentation of content that mmmfs encourages. 
 
-As a result, the experiences of interacting with the system at large is still a very different experience than 
-editing content (and thereby extending the system) in it. This is expected to represent a major hurdle for users
-getting started with the system, and is a major shortcoming in enabling end-user programming as set as a goal for
+As a result, interacting with the system at large is still a very different experience than  editing content (and
+thereby extending the system) in it. This is expected to represent a major hurdle for users getting started with the
+system, and is a major shortcoming in enabling end-user programming as set as a goal for
 this project. A future iteration should take care to reconsider how editing can be integrated more holistically
 with the other core concepts of the design.
diff --git a/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon
index a553f8d..c79ffcf 100644
--- a/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon
+++ b/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon
@@ -4,7 +4,8 @@
 -- resolves to a value of type mmm/dom
 =>
   html = require 'mmm.dom'
-  import h4, div, a, span from html
+  import h4, div, a, span, ul, li from html
+  import link_to from (require 'mmm.mmmfs.util') html
 
   -- render a preview block
   preview = (child) ->
@@ -14,23 +15,26 @@
     -- get 'preview' as a DOM description (nil if no value or conversion possible)
     content = child\get 'preview', 'mmm/dom'
 
-    div {
-      h4 title, style: { margin: 0, cursor: 'pointer' }, onclick: -> BROWSER\navigate child.path
-      content or span '(no renderable content)', style: { color: 'red' },
-      style: {
-        display: 'inline-block',
-        width: '300px',
-        height: '200px',
-        padding: '4px',
-        margin: '8px',
-        border: '4px solid #eeeeee',
-        overflow: 'hidden',
-      },
-    }
+    -- div {
+    --   h4 title, style: { margin: 0, cursor: 'pointer' }, onclick: -> BROWSER\navigate child.path
+    --   content or span '(no renderable content)', style: { color: 'red' },
+    --   style: {
+    --     display: 'inline-block',
+    --     width: '300px',
+    --     height: '200px',
+    --     padding: '4px',
+    --     margin: '8px',
+    --     border: '4px solid #eeeeee',
+    --     overflow: 'hidden',
+    --   },
+    -- }
 
-  content = for child in *@children
+    li link_to child
+
+  content = ul for child in *@children
     preview child
 
-  table.insert content, 1, (@gett 'intro: mmm/dom')
+  -- table.insert content, 1, (@gett 'intro: mmm/dom')
+  -- div content
 
-  div content
+  div (@gett 'intro: mmm/dom'), content
diff --git a/root/articles/mmmfs/framework/text$markdown+sidenotes.md b/root/articles/mmmfs/framework/text$markdown+sidenotes.md
index af446a5..6fa2d3a 100644
--- a/root/articles/mmmfs/framework/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/framework/text$markdown+sidenotes.md
@@ -1,52 +1,13 @@
-Two of the earliest wholistic computing systems, the Xerox Alto and Xerox Star, both developed at Xerox PARC and introduced in the 70s and early 80s, pioneered not only graphical user-interfaces, but also the "Desktop Metaphor".
-The desktop metaphor presents information as stored in "Documents" that can be organized in folders and on the "Desktop". It invokes a strong analogy to physical tools.
-One of the differences between the Xerox Star system and other systems at the time, as well as the systems we use currently, is that the type of data a file represents is directly known to the system.
+evaluation framework
+====================
 
-<div class="sidenote"><mmm-embed raw path="../references/xerox-star"></mmm-embed></div>
+In the following section, I will collect approaches and reviews of different end-user software systems from current
+literature, as well as derive and present my own requirements and guiding principles for the development of a new system.
 
-> In a Desktop metaphor system, users deal mainly with data files, oblivious to the existence of programs.
-> They do not "invoke a text editor", they "open a document".
-> The system knows the type of each file and notifies the relevant application program when one is opened.
->
-> The disadvantage of assigning data files to applications is that users sometimes want to operate on a file with a program other than
-its "assigned" application. \[...\]
-> Star's designers feel that, for its audience, the advantages of allowing users to forget
-about programs outweighs this disadvantage.
-
-Other systems at the time lacked any knowledge of the type of files,
-and while mainstream operating systems of today have retro-fit the ability to associate and memorize the preferred applications to use for a given file based on it's name suffix, the intention of making applications a secondary, technical detail of working with the computer has surely been lost.
-
-Another design detail of the Star system is the concept of "properties" that are stored for "objects" throughout the system (the objects being anything from files to characters or paragraphs).
-These typed pieces of information are labelled with a name and persistently stored, providing a mechanism to store metadata such as user preference for ordering or defaut view of a folder for example.
-
-***
-
-Fig. 8 - Star Retrospective
-
-The earliest indirect influence for the Xerox Alto and many other systems of its time,
-was the *Memex*. The *Memex* is a hypothetical device and system for knowledge management.
-Proposed by Vannevar Bush in 1945, the concept predates much of the technology that later was used to implement many parts of the vision. In essence, the concept of hypertext was invented.
-
-***
-
-One of the systems that could be said to have come closest to a practical implementation of the Memex might be Apple's *Hypercard*.
-
-https://archive.org/details/CC501_hypercard
-
-"So I can have the information in these stacks tied together in a way that makes sense"
-
-In a demonstration video, the creators of the software showcase a system of stacks of cards that together implement, amongst others, a calendar (with yearly and weekly views), a list of digital business cards for storing phone numbers and addresses, and a todo list.
-However these stacks of cards are not just usable by themselves, it is also demonstrated how stacks can link to each other in meaningful ways, such as jumping to the card corresponding to a specific day from the yearly calendar view, or automatically looking up the card corresponding to a person's first name from a mention of the name in the text on a different card.
-
-Alongside Spreadsheets, *Hypercard* remains one of the most successful implementations of end-user programming, even today.
-While it's technical abilities have been long matched and passed by other software (such as the ubiquitous HTML hypertext markup language), these technical successors have failed the legacy of *Hypercard* as an end-user tool:
-while it is easier than ever to publish content on the web (through various social media and microblogging services), the benefits of hypermedia as a customizable medium for personal management have nearly vanished.
-End-users do not create hypertext anymore.
-
-The *UNIX Philosophy* <mmm-link path="../references/unix"></mmm-link>
-describes the software design paradigm pioneered in the creation of the Unix operating system at the AT&T Bell Labs
-research center in the 1960s. The concepts are considered quite influental and are still notably applied in the Linux community.
-Many attempts at summaries exist, but the following includes the pieces that are especially relevant even today:
+The *UNIX Philosophy* <mmm-link path="../references/unix"></mmm-link> describes the software design paradigm
+pioneered in the creation of the Unix operating system at the AT&T Bell Labs research center in the 1960s. The
+concepts are considered quite influental and are still notably applied in the Linux community. Many attempts at
+summaries exist, but the following includes the pieces that are especially relevant even today:
 
 > Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well.
 > Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be
@@ -54,14 +15,12 @@ Many attempts at summaries exist, but the following includes the pieces that are
 > than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs,
 > become general and useful tools.
 
-This approach has multiple benefits with regard to end-user programmability:
-Assembling the system out of simple, modular pieces means that for any given task a user may want to implement,
-it is very likely that preexisting parts of the system can help the user realize a solution.
-Wherever such a preexisting part exists, it pays off designing it in such a way that it is easy to integrate for the user later.
-Assembling the system as a collection of modular, interacting pieces also enables future growth and customization,
-since pieces may be swapped out with customized or alternate software at any time. 
-
-***
+This approach has multiple benefits with regard to end-user programmability: Assembling the system out of simple,
+modular pieces means that for any given task a user may want to implement, it is very likely that preexisting parts
+of the system can help the user realize a solution. Wherever such a preexisting part exists, it pays off designing it
+in such a way that it is easy to integrate for the user later. Assembling the system as a collection of modular,
+interacting pieces also enables future growth and customization, since pieces may be swapped out with customized or
+alternate software at any time. 
 
 Based on this, a modern data storage and processing ecosystem should enable transclusion of both content and behaviours
 between contexts.
diff --git a/root/articles/mmmfs/historical-approaches/$order b/root/articles/mmmfs/historical-approaches/$order
new file mode 100644
index 0000000..b98a91b
--- /dev/null
+++ b/root/articles/mmmfs/historical-approaches/$order
@@ -0,0 +1 @@
+star-graph
diff --git a/root/articles/mmmfs/historical-approaches/star-graph/image$png.png b/root/articles/mmmfs/historical-approaches/star-graph/image$png.png
new file mode 100644
index 0000000..ed4003c
--- /dev/null
+++ b/root/articles/mmmfs/historical-approaches/star-graph/image$png.png
diff --git a/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md b/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md
new file mode 100644
index 0000000..ebbe51c
--- /dev/null
+++ b/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md
@@ -0,0 +1,71 @@
+historical approaches
+=====================
+
+Two of the earliest wholistic computing systems, the Xerox Alto and Xerox Star, both developed at Xerox PARC and
+introduced in the 70s and early 80s, pioneered not only graphical user-interfaces, but also the "Desktop Metaphor".
+The desktop metaphor presents information as stored in "Documents" that can be organized in folders and on the
+"Desktop". It invokes a strong analogy to physical tools. One of the differences between the Xerox Star system and
+other systems at the time, as well as the systems we use currently, is that the type of data a file represents is
+directly known to the system.
+
+In a retrospective analysis of the Xerox Star's impact on the computer
+industry<mmm-link path="../references/xerox-star" ></mmm-link>, the desktop metaphor is described as follows:
+
+> In a Desktop metaphor system, users deal mainly with data files, oblivious to the existence of programs.
+> They do not "invoke a text editor", they "open a document".
+> The system knows the type of each file and notifies the relevant application program when one is opened.
+>
+> The disadvantage of assigning data files to applications is that users sometimes want to operate on a file with a
+> program other than its "assigned" application. \[...\]
+> Star's designers feel that, for its audience, the advantages of allowing users to forget about programs outweighs
+> this disadvantage.
+
+Other systems at the time lacked any knowledge of the type of files, and while mainstream operating systems of today
+have retro-fit the ability to associate and memorize the preferred applications to use for a given file based on it's
+name suffix, the intention of making applications a secondary, technical detail of working with the computer has
+surely been lost.
+
+Another design detail of the Star system is the concept of "properties" that are stored for "objects" throughout the
+system (the objects being anything from files to characters or paragraphs). These typed pieces of information are
+labelled with a name and persistently stored, providing a mechanism to store metadata such as user preference for
+ordering or the defaut view mode of a folder for example.
+
+<div class="sidenote" style="margin-top: 1rem;">
+<p><i>How systems influenced later systems. This graph summarizes how various systems related to Star have influenced
+one another over the years. Time progresses downwards. Double arrows indicate direct successors (i.e.,
+follow-on versions). [...]</i></p>
+<mmm-embed raw path="../references/xerox-star"></mmm-embed></div>
+<mmm-embed nolink path="star-graph"></mmm-embed>
+
+The earliest indirect influence for the Xerox Alto and many other systems of its time, was the *Memex*.
+The *Memex* is a hypothetical device and system for knowledge management. Proposed by Vannevar Bush in 1945<mmm-link
+path="../references/memex"></mmm-link>, the concept predates much of the technology that later was used to implement
+many parts of the vision.
+
+While the article extrapolates from existing technology at the time, describing at times
+very concrete machinery based on microfilm and mechanical contraptions, many of the conceptual predictions became
+true or inspired  ....
+
+One of the most innovative elements of Bush's predictions is the idea of technologically cross-referenced and
+connected information, which would later be known and created as *hypertext*. While hypertext powers the majority of
+today's internet, many of the advantages that Bush imagined have not carried over into the personal use of computers.
+There are very few tools for creating personal, highly-interconnected knowledgebases, even though this is technically
+feasible, and a proven concept (exemplified for example by the massively successful online encyclopedia *Wikipedia*<mmm-link
+path="../references/wikipedia"></mmm-link>).
+
+While there are little such tools available today, one of the systems that could be said to have come closest to a
+practical implementation of such a Memex-inspired system for personal use might be Apple's *HyperCard*.
+
+In a live demonstration<mmm-link path="../references/hypercard"></mmm-link>, the creators of the software showcase
+a system of stacks of cards that together implement, amongst others, a calendar (with yearly and weekly views), a
+list of digital business cards for storing phone numbers and addresses, and a todo list. However these stacks of
+cards are not just usable by themselves, it is also demonstrated how stacks can link to each other in meaningful ways,
+such as jumping to the card corresponding to a specific day from the yearly calendar view, or automatically looking
+up the card corresponding to a person's first name from a mention of the name in the text on a different card.
+
+Alongside Spreadsheets, *HyperCard* remains one of the most successful implementations of end-user programming, even
+today. While it's technical abilities have been long matched and surpassed by other software (such as the ubiquitous
+*Hypertext Markup Language*, HTML), these technical successors have failed the legacy of *HyperCard* as an end-user
+tool: while it is easier than ever to publish content on the web (through various social media and microblogging
+services), the benefits of hypermedia as a customizable medium for personal management have nearly vanished.
+End-users do not create hypertext anymore.
diff --git a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md
index 7a682dd..aa09173 100644
--- a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md
@@ -1,8 +1,17 @@
-# mmmfs
-`mmmfs` seeks to improve on two fronts.
+mmmfs
+=====
 
-One of the main driving ideas of the mmmfs is to help data portability and use by making it simpler to inter-operate with different data formats.
-This is accomplished using two major components, the *Type System and Coercion Engine* and the *Fileder Unified Data Model* for unified data storage and access.
+`mmmfs` is a newly developed personal data storage and processing system. It was developed first as a tool for
+generating static websites, but has been extended with live interaction and introspection, as well as embedded
+editing capabilities as part of this work.
+
+mmmfs has been designed with a focus on data ownership for users. One of the main driving ideas is to unlock data
+from external data silos and file formats by making data available uniformly across different storage systems and
+formats. Secondly, computation and interactive elements are also integrated in the paradigm, so that mmmfs can be
+seemlessly extended and molded to the users needs.
+
+The abstraction of data types is accomplished using two major components, the *Type System and Coercion Engine* and
+the *Fileder Unified Data Model* for unified data storage and access.
 
 ## the fileder unified data model
 The Fileder Model is the underlying unified data storage model.
@@ -20,7 +29,6 @@ but notably the type of data is generally not actually stored in the filesystem,
 but determined loosely based on multiple heuristics depending on the system and context.
 Some notable mechanism are:
 
-
 - Suffixes in the name are often used to indicate what kind of data a file should contain. However there is no standardization
 - over this, and often a suffix is used for multiple incompatible versions of a file-format.
 - Many file-formats specify a specific data-pattern either at the very beginning or very end of a given file.
@@ -37,9 +45,9 @@ Because these various mechanisms are applied at different times by the operating
 it is possible for files to be labelled as or considered as being in different formats at the same time by different components of the system.
 <div class="sidenote" style="margin-top: -5rem;">
 The difference between changing a file extension and converting a file between two formats is commonly unclear to users,
-for example: see <a href="https://askubuntu.com/questions/166602/why-is-it-possible-to-convert-a-file-just-by-renaming-its-extension">
-Why is it possible to convert a file just by renaming it?</a>, https://askubuntu.com/q/166602 
-<!-- https://www.quora.com/What-happens-when-you-rename-a-jpg-to-a-png-file --> from 2019-12-18
+see for example <a href="https://askubuntu.com/questions/166602/why-is-it-possible-to-convert-a-file-just-by-renaming-its-extension">
+Why is it possible to convert a file just by renaming it?</a>, https://askubuntu.com/q/166602 from 2019-12-18
+<!-- https://www.quora.com/What-happens-when-you-rename-a-jpg-to-a-png-file -->
 </div>
 This leads to confusion about the factual format of data among users, but can also pose a serious security risk:
 Under some circumstances it is possible that a file contains maliciously-crafted code and is treated as an executable
@@ -161,9 +169,7 @@ Cost is defined in this way to make sure that the result of a type-coercion oper
 It is also important to prevent some nonsensical results from occuring, such as displaying a link to content instead of the content itself because
 the link requires less steps to create than completely converting the content does.
 
-***
-
-Type coercion is implemented using a general pathfinding algorithm, similar to A*.
+Type coercion is implemented using a general pathfinding algorithm, similar to A\*.
 First, the set of given *types* is found by selecting all *facets* of the *fileder* that match the *name* given in the query.
 The set of given *types* is marked in green in the following example graph.
 
diff --git a/root/articles/mmmfs/problem-statement/text$markdown+sidenotes.md b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
index 4723f01..e178f4a 100644
--- a/root/articles/mmmfs/problem-statement/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
@@ -1,4 +1,5 @@
-# motivation
+motivation
+==========
 
 The majority of users interacts with modern computing systems in the form of smartphones, laptops or desktop PCs,
 using the mainstream operating systems Apple iOS and Mac OS X, Microsoft Windows or Android.
@@ -45,11 +46,20 @@ If the word-processing application supports this,
 the old image may be replaced directly, otherwise the user may have to remove the old image,
 insert the new one and carefully ensure that the positioning in the document remains intact.
 
+Let us take as an example the simple task of collecting and arranging a mixed collection of images, videos
+and texts in order to brainstorm. To create an assemblage of pictures and text, many might be tempted to open an
+Application like Microsoft Word or Adobe Photoshop and create a new document there. Both photoshop files and
+word documents are capable of containing texts and images, but when the files are saved, direct access to the
+contained data is lost. It is for example a non-trivial and unenjoyable task to edit an image file contained
+in a word document in another application and have the changes apply to the document. In the same way,
+text contained in a photoshop document cannot be edited in a text editor of your choice.
+
+
 https://www.theverge.com/2019/10/7/20904030/adobe-venezuela-photoshop-behance-us-sanctions
 
 
 The application-centric computing paradigm common today is harmful to users,
-because it leaves behind "intert" data as D. Cragg calls it:
+because it leaves behind "inert" data, as D. Cragg calls it:
 
 [Cragg 2016]
 D. Cragg coins the term "inert data" for the data created, and left behind, by apps and applications in the computing model that is currently prevalent:
@@ -75,17 +85,12 @@ in a separate 'file' (as the metaphora may have initially suggested),
 but rather keeps this database hidden away from the user.
 Consequently, access to the information contained in the database is only enabled through the contacts applications GUI.
 
---
-
-According to some researchers in the field of Human-Computer-Interaction, the state of computing is rather dire.
-
-It seems that a huge majority of daily computer users have silently accepted
-that real control over their most important everyday tool will be forever out of reach,
-and surrendered it to the relatively small group of 'programmers' curating their experience.
-
-- Applications are bad
-- Services are worse
+<div class="sidenote">Note that 'creative' here does not only mean 'artistic': this applies to any field, and it limits the
+ability of domain experts to push the boundaries of practice by using technology in innovative ways.</div>
+Creative use of computer technology is limited to programmers, since applications constrain their users to the
+paths and abilities that the developers anticipated and deemed useful.
 
+--
 
 Chiusano blames these issues on the metaphor of the *machine*, and likens apps and applications to appliances.
 According to him, what should really be provided are *tools*:
@@ -113,16 +118,3 @@ experience to give control back to and empower users.
 mmmfs tries to provide a filesystem that is powerful enough to let you use it as your canvas for thinking,
 and working at the computer.  mmmfs is made for more than just storing information. Files in mmmfs can interact
 and morph to create complex behaviours.
-
-Let us take as an example the simple task of collecting and arranging a mixed collection of images, videos
-and texts in order to brainstorm. To create an assemblage of pictures and text, many might be tempted to open an
-Application like Microsoft Word or Adobe Photoshop and create a new document there. Both photoshop files and
-word documents are capable of containing texts and images, but when the files are saved, direct access to the
-contained data is lost. It is for example a non-trivial and unenjoyable task to edit an image file contained
-in a word document in another application and have the changes apply to the document. In the same way,
-text contained in a photoshop document cannot be edited in a text editor of your choice.
-
-Creative use of computer technology is limited to programmers, since applications constrain their users to the
-paths and abilities that the developers anticipated and deemed useful.
-Note that 'creative' here does not only encompass 'artistic': this applies to any field and means
-that innovative use of technology is unlikely to happen as a result of practice by domain experts.
diff --git a/root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon
new file mode 100644
index 0000000..693d362
--- /dev/null
+++ b/root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon
@@ -0,0 +1,51 @@
+-- main content
+-- doesn't have a name prefix (e.g. preview: fn -> mmm/dom)
+-- uses the 'fn ->' conversion to execute the lua function on @get
+-- resolves to a value of type mmm/dom
+=>
+  html = require 'mmm.dom'
+  import article, h1, h2, h3, section, p, div, a, sup, ol, li, span, code, pre, br from html
+  import moon from (require 'mmm.highlighting').languages
+
+  article with _this = class: 'sidenote-container', style: { 'max-width': '640px' }
+    append = (a) -> table.insert _this, a
+
+    footnote, getnotes = do
+      local *
+      notes = {}
+
+      id = (i) -> "footnote-#{i}"
+
+      footnote = (stuff) ->
+        i = #notes + 1
+        notes[i] = stuff
+        sup a "[#{i}]", style: { 'text-decoration': 'none' }, href: '#' .. id i
+
+      footnote, ->
+        args = for i, note in ipairs notes
+          li (span (tostring i), id: id i), ': ', note
+        notes = {}
+        table.insert args, style: { 'list-style': 'none', 'font-size': '0.8em' }
+        ol table.unpack args
+
+    append h1 'Empowered End-User Computing', style: { 'margin-bottom': 0 }
+    append p "A Historical Investigation and Development of a File-System-Based Environment", style: { 'margin-top': 0, 'padding-bottom': '0.2em', 'border-bottom': '1px solid black' }
+
+    -- render a preview block
+    do_section = (child) ->
+      -- get 'title' as 'text/plain' (error if no value or conversion possible)
+      title = (child\get 'title: text/plain') or child\gett 'name: alpha'
+
+      -- get 'preview' as a DOM description (nil if no value or conversion possible)
+      content = (child\get 'preview: mmm/dom') or child\get 'mmm/dom'
+
+      section {
+        h3 title, style: { margin: 0, cursor: 'pointer' }, onclick: -> BROWSER\navigate child.path
+        content or span '(no renderable content)', style: { color: 'red' },
+      }
+
+    for child in *@children
+      append (child\get 'print: mmm/dom') or (child\gett 'mmm/dom')
+      -- do_section child
+
+    append getnotes!
diff --git a/root/articles/mmmfs/references/$order b/root/articles/mmmfs/references/$order
index 2388177..96b5c98 100644
--- a/root/articles/mmmfs/references/$order
+++ b/root/articles/mmmfs/references/$order
@@ -1,4 +1,7 @@
 xerox-star
+memex
+hypercard
+wikipedia
 unix
 subtext
 inkandswitch
diff --git a/root/articles/mmmfs/references/aspect-ratios/text$bibtex b/root/articles/mmmfs/references/aspect-ratios/text$bibtex
index 6536419..37cea92 100644
--- a/root/articles/mmmfs/references/aspect-ratios/text$bibtex
+++ b/root/articles/mmmfs/references/aspect-ratios/text$bibtex
@@ -1,7 +1,7 @@
 @web{aspect:ratios,
   title = {Aspect-ratio independent UIs},
   url = {https://s-ol.nu/aspect-ratios},
-  author = {Bekic, S.}
+  author = {Bekic, Sol}
   year = {2019},
   visited = {2019-12-18},
 }
diff --git a/root/articles/mmmfs/references/hypercard/text$bibtex b/root/articles/mmmfs/references/hypercard/text$bibtex
new file mode 100644
index 0000000..b23cfcb
--- /dev/null
+++ b/root/articles/mmmfs/references/hypercard/text$bibtex
@@ -0,0 +1,6 @@
+@online{hypercard,
+  title = {Computer Chronicles, Episode 501},
+  url = {https://archive.org/details/CC501_hypercard},
+  visited = {2019-12-18},
+  year = {1987},
+}
diff --git a/root/articles/mmmfs/references/linux-exec/text$bibtex b/root/articles/mmmfs/references/linux-exec/text$bibtex
index 6d52aa8..4f39fef 100644
--- a/root/articles/mmmfs/references/linux-exec/text$bibtex
+++ b/root/articles/mmmfs/references/linux-exec/text$bibtex
@@ -1,4 +1,4 @@
-@web{23295968,
+@web{linux:exec,
   title = {How does Linux execute a file?},
   url = {https://stackoverflow.com/a/23295724/1598293},
   publisher = {stackoverflow.com},
diff --git a/root/articles/mmmfs/references/memex/text$bibtex b/root/articles/mmmfs/references/memex/text$bibtex
new file mode 100644
index 0000000..377d756
--- /dev/null
+++ b/root/articles/mmmfs/references/memex/text$bibtex
@@ -0,0 +1,8 @@
+@article{memex,
+  author = {Bush, Vannevar},
+  title = {As we may think},
+  journal = {Atlantic Monthly},
+  year = {1945},
+  volume = {176},
+  pages = {101-108},
+}
diff --git a/root/articles/mmmfs/references/poc-or-gtfo/text$bibtex b/root/articles/mmmfs/references/poc-or-gtfo/text$bibtex
index 26dda65..7cac092 100644
--- a/root/articles/mmmfs/references/poc-or-gtfo/text$bibtex
+++ b/root/articles/mmmfs/references/poc-or-gtfo/text$bibtex
@@ -2,5 +2,7 @@
   author = {Albertini, Ange},
   title = {Abusing file formats; or, Corkami, the Novella},
   year = {2015},
-  journal = {PoC||GTFO 7},
+  journal = {PoC||GTFO},
+  volume = {7},
+  pages = {18-41},
 }
diff --git a/root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon
index 7b86510..333900b 100644
--- a/root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon
+++ b/root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon
@@ -1,6 +1,9 @@
 =>
   html = require 'mmm.dom'
-  import ol, li from html
+  import div, h1, ol, li from html
 
-  ol for ref in *@children
-    li ref\gett 'mmm/dom'
+  div {
+    h1 "references"
+    ol for ref in *@children
+      li ref\gett 'mmm/dom'
+  }
diff --git a/root/articles/mmmfs/references/wikipedia/text$bibtex b/root/articles/mmmfs/references/wikipedia/text$bibtex
new file mode 100644
index 0000000..c83b72c
--- /dev/null
+++ b/root/articles/mmmfs/references/wikipedia/text$bibtex
@@ -0,0 +1,6 @@
+@web{wikipedia,
+  title = {Hyperlink - Wikis},
+  url = {https://en.wikipedia.org/wiki/Hyperlink#Wikis},
+  publisher = {wikipedia.org},
+  visited = {2019-12-18},
+}
diff --git a/root/articles/mmmfs/references/xerox-star/text$bibtex b/root/articles/mmmfs/references/xerox-star/text$bibtex
new file mode 100644
index 0000000..a75cc3e
--- /dev/null
+++ b/root/articles/mmmfs/references/xerox-star/text$bibtex
@@ -0,0 +1,17 @@
+@article{xerox:star,
+ author = {Johnson, Jeff et. al},
+ title = {The Xerox Star: A Retrospective},
+ journal = {Computer},
+ issue_date = {September 1989},
+ volume = {22},
+ number = {9},
+ month = sep,
+ year = {1989},
+ issn = {0018-9162},
+ pages = {11-26, 28-29},
+ url = {http://dx.doi.org/10.1109/2.35211},
+ doi = {10.1109/2.35211},
+ acmid = {66894},
+ publisher = {IEEE Computer Society Press},
+ address = {Los Alamitos, CA, USA},
+}