aboutsummaryrefslogtreecommitdiffstats
path: root/root/articles
diff options
context:
space:
mode:
authors-ol <s-ol@users.noreply.github.com>2019-12-29 17:56:23 +0000
committers-ol <s-ol@users.noreply.github.com>2019-12-29 17:56:23 +0000
commitb0b26d2a9dcd4944d9aae90480591793691730c1 (patch)
tree18d6205b61d3a70ad74374c57942edc5d0af0c3e /root/articles
parentclean up editor a bit (diff)
downloadmmm-b0b26d2a9dcd4944d9aae90480591793691730c1.tar.gz
mmm-b0b26d2a9dcd4944d9aae90480591793691730c1.zip
marginnote embedding
Diffstat (limited to 'root/articles')
-rw-r--r--root/articles/mmmfs/evaluation/text$markdown+sidenotes.md6
-rw-r--r--root/articles/mmmfs/framework/text$markdown+sidenotes.md7
-rw-r--r--root/articles/mmmfs/historical-approaches/star-graph/note: text$markdown.md4
-rw-r--r--root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md8
-rw-r--r--root/articles/mmmfs/mmmfs/$order1
-rw-r--r--root/articles/mmmfs/mmmfs/confusion/text$markdown.md5
-rw-r--r--root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md7
-rw-r--r--root/articles/mmmfs/motivation/$order1
-rw-r--r--root/articles/mmmfs/motivation/creative/text$markdown.md2
-rw-r--r--root/articles/mmmfs/motivation/text$markdown+sidenotes.md6
-rw-r--r--root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon2
-rw-r--r--root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon6
-rw-r--r--root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon2
13 files changed, 33 insertions, 24 deletions
diff --git a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
index 8c6404e..f44e18b 100644
--- a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
@@ -93,9 +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.
-<div class="sidenote">see also <mmm-embed wrap="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.
+<mmm-embed wrap="marginnote" path="../references/alternatives-to-trees">See also </mmm-embed>
+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 0e4d9a3..48e6a2c 100644
--- a/root/articles/mmmfs/framework/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/framework/text$markdown+sidenotes.md
@@ -56,9 +56,10 @@ content transclusion
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 wrap="raw" path="../references/transclusion"></mmm-embed></span>*transcluded*,
+linked to (as envisioned for the *Memex*, see above), but also to be <mmm-embed wrap="marginnote"
+path="../references/transclusion">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>*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
diff --git a/root/articles/mmmfs/historical-approaches/star-graph/note: text$markdown.md b/root/articles/mmmfs/historical-approaches/star-graph/note: text$markdown.md
new file mode 100644
index 0000000..eb115dd
--- /dev/null
+++ b/root/articles/mmmfs/historical-approaches/star-graph/note: text$markdown.md
@@ -0,0 +1,4 @@
+<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 wrap="raw" path="../../references/xerox-star"></mmm-embed>
diff --git a/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md b/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md
index 62b21a0..dff153a 100644
--- a/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md
@@ -31,12 +31,8 @@ system (the objects being anything from files to characters or paragraphs). Thes
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 wrap="raw" path="../references/xerox-star"></mmm-embed></div>
-<mmm-embed nolink path="star-graph"></mmm-embed>
+<mmm-embed path="star-graph" facet="note" wrap="marginnote" style="margin-top: 1rem;"></mmm-embed>
+<mmm-embed path="star-graph" nolink></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-embed
diff --git a/root/articles/mmmfs/mmmfs/$order b/root/articles/mmmfs/mmmfs/$order
index 5a5d5ab..ec11aa6 100644
--- a/root/articles/mmmfs/mmmfs/$order
+++ b/root/articles/mmmfs/mmmfs/$order
@@ -1,3 +1,4 @@
+confusion
type_coercion_graph
tree_mmmfs
tree_mainstream
diff --git a/root/articles/mmmfs/mmmfs/confusion/text$markdown.md b/root/articles/mmmfs/mmmfs/confusion/text$markdown.md
new file mode 100644
index 0000000..55fe833
--- /dev/null
+++ b/root/articles/mmmfs/mmmfs/confusion/text$markdown.md
@@ -0,0 +1,5 @@
+For example, the difference between changing a file extension and converting a file between two formats is often unclear
+to users, as evident from questions like this: <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 -->
diff --git a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md
index 9978fcf..bf1ed9b 100644
--- a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md
@@ -44,12 +44,7 @@ running on them, the format of a file is almost completely unknown and at best e
Because these various mechanisms are applied at different times by the operating system and applications,
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,
-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>
+<mmm-embed path="confusion" wrap="marginnote" style="margin-top: -5rem;"></mmm-embed>
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
by one software component, while a security mechanism meant to detect such code determines the same file to be a
diff --git a/root/articles/mmmfs/motivation/$order b/root/articles/mmmfs/motivation/$order
new file mode 100644
index 0000000..c327490
--- /dev/null
+++ b/root/articles/mmmfs/motivation/$order
@@ -0,0 +1 @@
+creative
diff --git a/root/articles/mmmfs/motivation/creative/text$markdown.md b/root/articles/mmmfs/motivation/creative/text$markdown.md
new file mode 100644
index 0000000..9dd6162
--- /dev/null
+++ b/root/articles/mmmfs/motivation/creative/text$markdown.md
@@ -0,0 +1,2 @@
+Note that 'creative' here does not only mean 'artistic': this applies to any field, and limits the ability of domain
+experts to push the boundaries of practice by using technology in innovative ways.
diff --git a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
index c3eb637..f0c2e6c 100644
--- a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
@@ -11,12 +11,15 @@ All of these operating systems share the concept of *Applications* (or *Apps*) a
interaction model. Functionality and capabilities of the digital devices are bundled in, marketed, sold and distributed
as applications.
+<!-- native vs other vs new ?? -->
+<!-- limitations not mentioned yet -->
In addition, a lot of functionality is nowadays delivered in the form of *Web Apps* or *Cloud Services*, which share the
limitations of native applications in addition to more specific issues that will be discussed in a separate section
below.
This focus on applications as the primary unit of systems can be seen as the root cause of multiple problems.
+<!-- rephrase vvv -->
For one, since applications are the products companies produce, and software represents a market of users,
developers compete on features integrated into their applications. To stay relevant, monlithic software or software
suites tend to accrete features rather then modularise and delegate to other software<mmm-embed wrap="sidenote"
@@ -37,8 +40,7 @@ developed by experts in application development, rather than experts in the doma
solicit feedback, advice and ideas from domain experts, communication is a barrier. Additionally, domain experts are
generally unfamiliar with the technical possibilities, and may therefore not be able to express feedback that would lead
to more significant advances.
-<div class="sidenote">Note that 'creative' here does not only mean 'artistic': this applies to any field, and limits
-the ability of domain experts to push the boundaries of practice by using technology in innovative ways.</div>
+<mmm-embed path="creative" wrap="marginnote"></mmm-embed>
As a result, 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.
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..0dac590 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', 'line-height': '1.5' }
append = (a) -> table.insert _this, a
footnote, getnotes = do
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 333900b..59b5c54 100644
--- a/root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon
+++ b/root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon
@@ -2,8 +2,10 @@
html = require 'mmm.dom'
import div, h1, ol, li from html
+ refs = for ref in *@children
+ li ref\gett 'mmm/dom'
div {
h1 "references"
- ol for ref in *@children
- li ref\gett 'mmm/dom'
+ ol with refs
+ refs.style = 'line-height': 'normal'
}
diff --git a/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon
index 8034805..1939042 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', 'line-height': '1.5' }
append = (a) -> table.insert _this, a
footnote, getnotes = do