more write- and referencing

7 files changed, 86 insertions, 39 deletions

diff --git a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
index 812b0c5..abde2fb 100644
--- a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
@@ -93,10 +93,9 @@ This way, *converts* can be added locally if they only make sense within a given
 Additionally it could be made possible to use this mechanism to locally override *converts* inherited from
 further up in the tree, for example to specialize types based on their context in the system.
 
-The biggest downside to this approach would be that it  presents another pressure factor for,
-while also reincforcing, the hierarchical organization of data,
-thereby exacerbating the limits of hierarchical structures.<div class="sidenote">see also
-<mmm-embed raw path="../references/alternatives-to-trees"></mmm-embed></div>
+<div class="sidenote">see also <mmm-embed raw path="../references/alternatives-to-trees"></mmm-embed>
+</div>The biggest downside to this approach would be that it  presents another pressure factor for, while also
+reincforcing, the hierarchical organization of data, thereby exacerbating the limits of hierarchical structures.
 
 ### code outside of the system
 At the moment, a large part of the mmmfs codebase is still separate from the content, and developed outside of mmmfs
diff --git a/root/articles/mmmfs/framework/text$markdown+sidenotes.md b/root/articles/mmmfs/framework/text$markdown+sidenotes.md
index 6fa2d3a..ec08ec4 100644
--- a/root/articles/mmmfs/framework/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/framework/text$markdown+sidenotes.md
@@ -2,41 +2,81 @@ evaluation framework
 ====================
 
 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.
+literature, as well as derive and present my own requirements and guiding principles for the development of a new
+system.
+
+qualities
+---------
+
+*Ink and Switch* suggest three qualities for tools striving to support
+end-user programming<mmm-link path="../references/inkandswitch"></mmm-link>:
+
+- *Embodiment*, i.e. reifying central concepts of the programming model as more concrete, tangible objects
+  in the digital space (for example through visual representation),
+  in order to reduce cognitive load on the user.
+- *Living System*, by which they seem to describe the malleability of a system or environment,
+  and in particular the ability to make changes at different levels of depth in the system with
+  very short feedback loops and a feeling of direct experience.
+- *In-place toolchain*, denoting the availability of tools to customize and author the experience,
+  as well as a certain accesibility of these tools, granted by a conceptual affinity between the
+  use of the tools and general 'passive' use of containing system at large. 
+
+These serve as guiding principles for the design and evaluation of computer systems for end-users, but are by nature
+very abstract. The following properties are therefore derived as more concrete proposals based on some more specific
+constraints: namely the construction of a system for end-users to keep, structure and display personal information and
+thoughts in.
+
+modularity
+----------
 
 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
-> written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs
-> than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs,
-> become general and useful tools.
+> 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 written down in a single sentence, at its heart is the idea that the power of a
+> system comes more from the relationships among programs 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. 
+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.
-Content should be able to be transcluded and referenced to facilitate the creation of flexible data formats and interactions,
-such that e.g. a slideshow slide can include content in a variety other formats (such as images and text) from anywhere else in the system.
-Behaviours should be able to be transcluded and reused to facilitate the creation of ad-hoc sytems and applets based on user needs.
-For example a user-created todo list should be able to take advantage of a sketching tool the user already has access to.
+Settling on a specific modular design model, and reifying other components of a system in terms of it also corresponds
+directly to the concept of *Embodiment* described by Ink & Switch.
 
-The system should enable the quick creation of ad-hoc software.
+content transclusion
+--------------------
 
-While there are drawbacks to cloud-storage of data (as outlined above), the utility of distributed systems is acknowledged,
-and the system should therefore be able to include content and behaviours via the network.
-This ability should be integrated deeply into the system,
-so that data can be treated independently of its origin and storage conditions, with as little caveats as possible.
+The strengths of modular architectures should similarily also extend into the way the system will be used by users.
+If users are to store their information and customized behaviour in such an architecture, then powerful tools need to be
+present in order to assemble more complex solutions out of such parts. Therefore static content should be able to be
+linked to (as envisioned for the *Memex*, see above), but also to be <span class="sidenote">The term <i>transclusion</i>
+refers to the concept of including content from a separate document, possibly stored remotely, by reference rather than
+by duplication. See also <mmm-embed raw path="../references/transclusion"></mmm-embed></span>*transcluded*,
+to facilitate the creation of flexible data formats and interactions, such that e.g. a slideshow slide can include
+content in a variety other formats (such as images and text) from anywhere else in the system. Behaviours also should be
+able to be transcluded and reused to facilitate the creation of ad-hoc sytems and applets based on user needs. For
+example a user-created todo list should be able to take advantage of a sketching tool the user already has access to.
 
-The system needs to be browsable and understandable by users.
+By forming the immediately user-visible layer of the system out of the same abstractions that the deeper levels of the
+system are made of, the sense of a *Living System* is also improved: skills that are learned at one (lower) level of the
+system carry on into further interaction with the system on deeper levels, as does progress in understanding the
+system's mechanisms.
+
+While there are drawbacks to cloud-storage of data (as outlined above), the utility of distributed systems is
+acknowledged, and the system should therefore be able to include content and behaviours via the network.
+This ability should be integrated deeply into the system, so that data can be treated independently of its origin and
+storage conditions, with as little caveats as possible. In particular, the interactions of remote data access and
+content transclusion should be paid attention to and taken into consideration for a system's design.
+
+end-user programming
+--------------------
 
 In order to provide users full access to their information as well as the computational infrastructure,
 users need to be able to finely customize and reorganize the smallest pieces to suit their own purposes,
@@ -49,16 +89,3 @@ in order to keep the scope of this work appropriate,
 conventional programming languages are used for the time being.
 Confidence is placed in the fact that eventually more user-friendly languages will be available and,
 given the goal of modularity, should be implementable in a straightforward fashion.
-
-*Ink and Switch* suggest three qualities for tools striving to support
-end-user programming<mmm-link path="../references/inkandswitch"></mmm-link>:
-
-- "Embodiment", i.e. reifying central concepts of the programming model as more concrete, tangible objects
-  in the digital space (for example through visual representation),
-  in order to reduce cognitive load on the user.
-- "Living System", by which they seem to describe the malleability of a system or environment,
-  and in particular the ability to make changes at different levels of depth in the system with
-  very short feedback loops and a feeling of direct experience.
-- "In-place toolchain", denoting the availability of tools to customize and author the experience,
-  as well as a certain accesibility of these tools, granted by a conceptual affinity between the
-  use of the tools and general 'passive' use of containing system at large. 
diff --git a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
index b8a5cac..4bc9cd4 100644
--- a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
@@ -51,7 +51,7 @@ Apple's *iOS* already started out as such so-called *walled gardens*.
 cloud computing
 ---------------
 
-*Web Apps* often offer similar functionality to other *Applications*, but are subject to additional limitations:
+*Web Apps* often offer similar functionality to other applications, but are subject to additional limitations:
 In most cases, they are only accessible or functional in the presence of a stable internet connection,
 and they have very limited access to the resources of the physical computer they are running on.
 For example, they usually cannot interact directly with the file system, hardware peripherals or other applications,
@@ -117,6 +117,16 @@ Rather than face this dilemma, a more sensible system could leave the task of po
 different types to one software component, while multiple different software components can be responsible for editing
 the individual pieces of content, so that the most appropriate one can be chosen for each element.
 
+<div style="height: 2rem;"></div>
+
+To summarize, for various reasons, the metaphors and interfaces of computing interfaces today prevent users from deeply
+understanding the software they use and the data they own, from customizing and improving their experience and
+interactions, and from properly owning, contextualising and connecting their data.
+
+Interestingly, these deficits do not appear throughout the history of todays computing systems, but are based in rather
+recent developments in the field. In fact the most influental systems in the past aspired to the polar opposites, as i
+will show in the next section.
+
 <!--
 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*:
diff --git a/root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon
index 693d362..48b18c4 100644
--- a/root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon
+++ b/root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon
@@ -7,7 +7,7 @@
   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' }
+  article with _this = class: 'sidenote-container', style: { 'max-width': '640px', 'text-align': 'justify' }
     append = (a) -> table.insert _this, a
 
     footnote, getnotes = do
diff --git a/root/articles/mmmfs/references/$order b/root/articles/mmmfs/references/$order
index 4fd79ec..01b0c04 100644
--- a/root/articles/mmmfs/references/$order
+++ b/root/articles/mmmfs/references/$order
@@ -15,3 +15,4 @@ poc-or-gtfo
 acm-dl
 aspect-ratios
 alternatives-to-trees
+transclusion
diff --git a/root/articles/mmmfs/references/transclusion/text$bibtex b/root/articles/mmmfs/references/transclusion/text$bibtex
new file mode 100644
index 0000000..e323662
--- /dev/null
+++ b/root/articles/mmmfs/references/transclusion/text$bibtex
@@ -0,0 +1,10 @@
+@article{article,
+  author = {Kolbitsch, Josef and Maurer, Hermann},
+  year = {2006},
+  month = {06},
+  pages = {161-173},
+  title = {Transclusions in an HTML-Based Environment},
+  volume = {14},
+  journal = {CIT},
+  doi = {10.2498/cit.2006.02.07},
+}
diff --git a/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon
index 8034805..371c0c8 100644
--- a/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon
+++ b/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon
@@ -7,7 +7,7 @@
   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' }
+  article with _this = class: 'sidenote-container', style: { 'max-width': '640px', 'text-align': 'justify' }
     append = (a) -> table.insert _this, a
 
     footnote, getnotes = do