git.s-ol.nu mmm / 2c39776
table-of-contents, reference order s-ol 1 year, 9 months ago
25 changed file(s) with 257 addition(s) and 178 deletion(s). Raw diff Collapse all Expand all
103103 link_to fileder, node, nil, opts.attr
104104
105105 when 'sidenote'
106 key = opts.desc or tostring refs\get!
106 key = tostring refs\get!
107107 id = "sideref-#{key}"
108108
109109 intext = sup a key, href: "##{id}"
00 title
11 abstract
2 table-of-contents
23 motivation
34 historical-approaches
45 framework
78 evaluation
89 conclusion
910 references
11 ba_log
1012 statement-of-originality
11 ba_log
0 The following pages document the development of the `mmmfs` system described above in the form of a project log.
1 Please note that the log has been written primarily for viewing using a web browser, and as such makes extensive use of
2 hyperlinking, and also includes some videos that cannot be reproduced in print. It is therefore recommended to view the
3 live version of the log online at the following address: [s-ol.nu/ba/log](https://s-ol.nu/ba/log).
55 div {
66 class: 'print-ownpage'
77
8 h1 link_to @, "appendix: project log"
8 h1 (link_to @, "appendix: project log"), id: 'ba-log'
9 @gett 'intro: mmm/dom'
910 table.unpack for post in *@children
1011 continue if post\get 'hidden: bool'
1112
33
44 =>
55 div {
6 h1 link_to @, "appendix: project log"
6 h1 (link_to @, "appendix: project log"), id: 'ba-log'
7 @gett 'intro: mmm/dom'
78 ul do
89 posts = for post in *@children
910 continue if post\get 'hidden: bool'
+0
-1
root/articles/mmmfs/ba_log/title: text$plain less more
0 project log
0 conclusion
1 ==========
0 # 7. conclusion
21
32 <div class="well well-warning">[section under construction]</div>
0 evaluation
1 ==========
0 # 6. evaluation
21
3 ## examples
2 ## 6.1 examples
43 In this section I will take a look at the implementations of the example for the use cases outlined above,
54 and evaluate them with regard to the framework derived in the corresponding section above.
65
7 ### publishing and blogging
6 ### 6.1.1 publishing and blogging
87 Since mmmfs has grown out of the need for a versatile CMS for a personal publishing website, it is not surprising to
98 see that it is still up to that job. Nevertheless it is worth taking a look at its strengths and weaknesses in this
109 context:
2423 separately from its parent and context in most cases. This has made the implementation of sidenotes less idiomatic
2524 than initially anticipated.
2625
27 ### pinwall
26 ### 6.1.2 pinwall
2827 The pinwall example shows some strenghts of the mmmfs system pretty convincingly.
2928 The type coercion layer completely abstracts away the complexities of transcluding different types of content,
3029 and only positioning and sizing the content, as well as enabling interaction, remain to handle in the pinwall fileder.
3938 UI layer (in this case the browser), which could feasibly be simplified through a custom abstraction layer or the use of
4039 output means other than the web.
4140
42 ### slideshow
41 ### 6.1.3 slideshow
4342 A simplified image slideshow example consists of only 20 lines of code and demonstrates how the reactive component
4443 framework simplifies the generation of ad-hoc UI dramatically:
4544
7069 The parts of the code dealing with the content are essentially identical, except that content is transcluded via the
7170 more general `mmm/dom` type-interface, allowing for a greater variety of types of content to be used as slides.
7271
73 ## general concerns
72 ## 6.2 general concerns
7473 While the system has proven pretty successful and moldable to the different use-cases that it has been tested in,
7574 there are also limitations in the proposed system that have become obvious in developing and working with the system.
7675 Some of these have been anticipated for some time and concrete research directions for solutions are apparent,
7776 while others may be intrinsic limitations in the approach taken.
7877
79 ### global set of converts
78 ### 6.2.1 global set of converts
8079 In the current system, there is only a single, global set of *converts* that can be potentially applied to facets
8180 anywhere in the system.
8281 Therefore it is necessary to encode behaviour directly (as code) in facets wherever exceptional behaviour is required.
9796 The biggest downside to this approach would be that it presents another pressure factor for, while also reincforcing,
9897 the hierarchical organization of data, thereby exacerbating the limits of hierarchical structures.
9998
100 ### code outside of the system
99 ### 6.2.2 code outside of the system
101100 At the moment, a large part of the mmmfs codebase is still separate from the content, and developed outside of mmmfs
102101 itself. This is a result of the development process of mmmfs and was necessary to start the project as the filesystem
103102 itself matured, but has now become a limitation of the user experience: potential users of mmmfs would generally start
114113 Both of these are expected to undergo changes as users adapt the system to their own content types and
115114 domains of interest, as well as their visual identity, respectively.
116115
117 ### type system
116 ### 6.2.3 type system
118117 The currently used type system based on strings and pattern matching has been largely satisfactory,
119118 but has proven problematic for some anticipated use cases.
120119 It should be considered to switch to a more intricate,
126125 Using these mechanisms for example images could be requested with a maximum-resolution constraint to save on bandwidth
127126 when embedded in other documents.
128127
129 ### type-coercion
128 ### 6.2.4 type-coercion
130129 By giving the system more information about the data it is dealing with,
131130 and then relying on the system to automatically transform between data-types,
132131 it is easy to lose track of which format data is concretely stored in.
141140 Emphasising the conversion process more strongly in this way might be a way to turn this feature from an opaque
142141 hindrance into a transparent tool. This should represent a challenge mostly in terms of UX and UI design.
143142
144 ### editing
143 ### 6.2.5 in-system editing
145144 Because many *converts* are not necessarily reversible, it is very hard to implement generic ways of editing stored data
146145 in the same format it is viewed. For example, the system trivially converts markdown-formatted text sources into
147146 viewable HTML markup, but it is hardly possible to propagate changes to the viewable HTML back to the markdown source.
0 ## 5.1 publishing and blogging
1 ### 5.1.1 blogging
2 Blogging is pretty straightforward, since it generally just involves publishing lightly-formatted text,
3 interspersed with media such as images and videos or perhaps social media posts.
4 Markdown is a great tool for this job, and has been integrated in the system to much success:
5 There are two different types registered with *converts*: `text/markdown` and `text/markdown+span`.
6 They both render to HTML (and DOM nodes), so they are immediately viewable as part of the system.
7 The only difference for `text/markdown+span` is that it is limited to a single line,
8 and doesn't render as a paragraph but rather just a line of text.
9 This makes it suitable for denoting formatted-text titles and other small strings of text.
10
11 The problem of embedding other content together with text comfortably is also solved easily,
12 because Markdown allows embedding arbitrary HTML in the document.
13 This made it possible to define a set of pseudo-HTML elements in the Markdown-convert,
14 `<mmm-embed>` and `<mmm-link>`, which respectively embed and link to other content native to mmm.
15
16 ### 5.1.2 scientific publishing
17 <div class="sidenote" style="margin-top: 1.25rem">
18 One of the 'standard' solutions, <a href="https://www.latex-project.org/">LaTeX</a>,
19 is arguably at least as complex as the mmm system proposed here, but has a much narrower scope,
20 since it does not support interaction.
21 </div>
22
23 Scientific publishing is notoriously complex, involving not only the transclusion of diagrams
24 and other media, but generally requiring precise and consistent control over formatting and layout.
25 Some of these complexities are tedious to manage, but present good opportunities for programmatic
26 systems and media to do work for the writer.
27
28 One such topic is the topic of references.
29 References appear in various formats at multiple positions in a scientific document;
30 usually they are referenced via a reduced visual form within the text of the document,
31 and then shown again with full details at the end of the document.
32
33 For the sake of this thesis, referencing has been implemented using a subset of the popular
34 BibTeX format for describing citations. Converts have been implemented for the `text/bibtex`
35 type to convert to a full reference format (to `mmm/dom`) and to an inline side-note reference
36 (`mmm/dom+link`) that can be transcluded using the `<mmm-link>` pseudo-tag.
37
38 For convenience, a convert from the `URL -> cite/acm` type has been provided to `URL -> text/bibtex`,
39 which generates links to the ACM Digital Library<mmm-embed path="../references/acm-dl" wrap="sidenote"></mmm-embed>
40 API for accessing BibTeX citations for documents in the library. This means that it is enough to store the link to the
41 ACM DL entry in mmmfs, and the reference will automatically be fetched, and therefore stay up to date with potential
42 remote corrections.
43
44 ## 5.2 pinwall
45 In many situations, in particular for creative work, it is often useful to compile resources of
46 different types for reference or inspiration, and arrange them spacially so that they can be viewed
47 at a glance or organized into different contexts etc.
48 Such a pinwall could serve for example to organise references to articles,
49 to collect visual inspiration for a moodboard etc.
50
51 As a collection, the Pinwall is primarily mapped to a Fileder in the system.
52 Any content that is placed within can then be rendered by the Pinwall,
53 which can constrain every piece of content to a rectangular piece on its canvas.
54 This is possible through a simple script, e.g. of the type `text/moonscript -> fn -> mmm/dom`,
55 which enumerates the list of children, wraps each in such a rectangular container,
56 and outputs the list of containers as DOM elements.
57
58 The position and size of each panel are stored in an ad-hoc facet, encoded in the JSON data format:
59 `pinwall_info: text/json`. Such a facet is set on each child and read whenever the script is called
60 to render the children, plugging the values within the facet into the visual styling of the document.
61
62 The script can also set event handlers that react to user input while the document is loaded,
63 and allow the user to reposition and resize the individual pinwall items by clicking and dragging
64 on the upper border or lower right-hand corner respectively.
65 Whenever a change is made the event handler can then update the value in the `pinwall_info` facet,
66 so that the updated position and size are stored for the next time the pinwall is opened.
67
68 ## 5.3 slideshow
69 Another common use of digital documents is as aids in a verbal presentation.
70 These often take the form of slideshows, for the creation of which a number of established applications exist.
71 In simple terms, a slideshow is simply a linear series of screen-sized documents, that can be
72 advanced (and rewound) one by one using keypresses.
73
74 The implementation of this is rather straightforward as well.
75 The slideshow as a whole becomes a fileder with a script that generates a designated viewport rectangle,
76 as well as a control interface with keys for advancing the active slide.
77 It also allows putting the browser into fullscreen mode to maximise screenspace and remove visual elements
78 of the website that may distract from the presentation, and register an event handler for keyboard accelerators
79 for moving through the presentation.
80
81 Finally the script simply embeds the first of its child-fileders into the viewport rectangle.
82 Once the current slide is changed, the next embedded child is simply chosen.
83
84 <!--
85 ## code documentation
86 /meta/mmm.dom/:%20text/html+interactive
87 -->
0 # examples
0 # 5. example use-cases
11 To illustrate the capabilities of the proposed system, and to compare the results with the framework introduced above,
22 a number of example use cases have been chosen and implemented from the perspective of a user.
33 In the following section I will introduce these use cases and briefly summarize the implementation
44 approach in terms of the capabilities of the proposed system.
55
6 ## publishing and blogging
7 ### blogging
8 Blogging is pretty straightforward, since it generally just involves publishing lightly-formatted text,
9 interspersed with media such as images and videos or perhaps social media posts.
10 Markdown is a great tool for this job, and has been integrated in the system to much success:
11 There are two different types registered with *converts*: `text/markdown` and `text/markdown+span`.
12 They both render to HTML (and DOM nodes), so they are immediately viewable as part of the system.
13 The only difference for `text/markdown+span` is that it is limited to a single line,
14 and doesn't render as a paragraph but rather just a line of text.
15 This makes it suitable for denoting formatted-text titles and other small strings of text.
16
17 The problem of embedding other content together with text comfortably is also solved easily,
18 because Markdown allows embedding arbitrary HTML in the document.
19 This made it possible to define a set of pseudo-HTML elements in the Markdown-convert,
20 `<mmm-embed>` and `<mmm-link>`, which respectively embed and link to other content native to mmm.
21
22 ### scientific publishing
23 <div class="sidenote" style="margin-top: 1.25rem">
24 One of the 'standard' solutions, <a href="https://www.latex-project.org/">LaTeX</a>,
25 is arguably at least as complex as the mmm system proposed here, but has a much narrower scope,
26 since it does not support interaction.
27 </div>
28
29 Scientific publishing is notoriously complex, involving not only the transclusion of diagrams
30 and other media, but generally requiring precise and consistent control over formatting and layout.
31 Some of these complexities are tedious to manage, but present good opportunities for programmatic
32 systems and media to do work for the writer.
33
34 One such topic is the topic of references.
35 References appear in various formats at multiple positions in a scientific document;
36 usually they are referenced via a reduced visual form within the text of the document,
37 and then shown again with full details at the end of the document.
38
39 For the sake of this thesis, referencing has been implemented using a subset of the popular
40 BibTeX format for describing citations. Converts have been implemented for the `text/bibtex`
41 type to convert to a full reference format (to `mmm/dom`) and to an inline side-note reference
42 (`mmm/dom+link`) that can be transcluded using the `<mmm-link>` pseudo-tag.
43
44 For convenience, a convert from the `URL -> cite/acm` type has been provided to `URL -> text/bibtex`,
45 which generates links to the ACM Digital Library<mmm-embed path="../references/acm-dl" wrap="sidenote"></mmm-embed>
46 API for accessing BibTeX citations for documents in the library. This means that it is enough to store the link to the
47 ACM DL entry in mmmfs, and the reference will automatically be fetched, and therefore stay up to date with potential
48 remote corrections.
49
50 ## pinwall
51 In many situations, in particular for creative work, it is often useful to compile resources of
52 different types for reference or inspiration, and arrange them spacially so that they can be viewed
53 at a glance or organized into different contexts etc.
54 Such a pinwall could serve for example to organise references to articles,
55 to collect visual inspiration for a moodboard etc.
56
57 As a collection, the Pinwall is primarily mapped to a Fileder in the system.
58 Any content that is placed within can then be rendered by the Pinwall,
59 which can constrain every piece of content to a rectangular piece on its canvas.
60 This is possible through a simple script, e.g. of the type `text/moonscript -> fn -> mmm/dom`,
61 which enumerates the list of children, wraps each in such a rectangular container,
62 and outputs the list of containers as DOM elements.
63
64 The position and size of each panel are stored in an ad-hoc facet, encoded in the JSON data format:
65 `pinwall_info: text/json`. Such a facet is set on each child and read whenever the script is called
66 to render the children, plugging the values within the facet into the visual styling of the document.
67
68 The script can also set event handlers that react to user input while the document is loaded,
69 and allow the user to reposition and resize the individual pinwall items by clicking and dragging
70 on the upper border or lower right-hand corner respectively.
71 Whenever a change is made the event handler can then update the value in the `pinwall_info` facet,
72 so that the updated position and size are stored for the next time the pinwall is opened.
73
74 ## slideshow
75 Another common use of digital documents is as aids in a verbal presentation.
76 These often take the form of slideshows, for the creation of which a number of established applications exist.
77 In simple terms, a slideshow is simply a linear series of screen-sized documents, that can be
78 advanced (and rewound) one by one using keypresses.
79
80 The implementation of this is rather straightforward as well.
81 The slideshow as a whole becomes a fileder with a script that generates a designated viewport rectangle,
82 as well as a control interface with keys for advancing the active slide.
83 It also allows putting the browser into fullscreen mode to maximise screenspace and remove visual elements
84 of the website that may distract from the presentation, and register an event handler for keyboard accelerators
85 for moving through the presentation.
86
87 Finally the script simply embeds the first of its child-fileders into the viewport rectangle.
88 Once the current slide is changed, the next embedded child is simply chosen.
89
90 <!--
91 ## code documentation
92 /meta/mmm.dom/:%20text/html+interactive
93 -->
6 <span class="sidenote">The online version is available at [s-ol.nu/ba](https://s-ol.nu/ba).</span>
7 The following examples can be viewed and inspected in the interactive version online:
3030
3131 li link_to child
3232
33 examples = div {
34 style:
35 position: 'relative'
36 'margin-top': '4rem'
33 examples = ul for child in *@children
34 preview child
3735
38 div "The online version is available at ", (a "s-ol.nu/ba", href: 'https://s-ol.nu/ba'), ".", class: 'sidenote'
39 "The following examples can be viewed and inspected in the interactive version online:"
40 ul for child in *@children
41 preview child
42 }
43
44 div (@gett 'intro: mmm/dom'), examples
36 div (@gett 'intro: mmm/dom'), examples, (@gett 'implementation: mmm/dom')
0 evaluation framework
1 ====================
0 # 3. evaluation framework
21
32 In the following section, I will collect approaches and reviews of different end-user software systems from current
43 literature, as well as derive and present my own requirements and guiding principles for the development of a new
54 system.
65
7 qualities
8 ---------
6 3.1 qualities of successful end-user computing
7 ----------------------------------------------
98
109 *Ink and Switch* suggest three qualities for tools striving to support
1110 end-user programming<mmm-embed path="../references/inkandswitch" wrap="sidenote"></mmm-embed>:
2524 constraints: namely the construction of a system for end-users to keep, structure and display personal information and
2625 thoughts.
2726
28 modularity
29 ----------
27 3.2 modularity
28 --------------
3029
3130 The *UNIX Philosophy*<mmm-embed path="../references/unix" wrap="sidenote"></mmm-embed> describes the software design
3231 paradigm pioneered in the creation of the Unix operating system at the AT&T Bell Labs research center in the 1960s. The
4948 Settling on a specific modular design model, and reifying other components of a system in terms of it, also corresponds
5049 directly to the concept of *Embodiment* described by Ink & Switch.
5150
52 content transclusion
53 --------------------
51 3.3 content transclusion
52 ------------------------
5453
5554 The strengths of modular architectures should similarily extend also into the way the system will be used by users.
5655 If users are to store their information and customized behaviour in such an architecture, then powerful tools need to be
7574 storage conditions, with as little caveats as possible. In particular, the interactions of remote data access and
7675 content transclusion should be paid attention to and taken into consideration for a system's design.
7776
78 end-user programming
79 --------------------
77 3.4 end-user programming
78 ------------------------
8079
8180 In order to provide users full access to their information as well as the computational infrastructure,
8281 users need to be able to finely customize and reorganize the smallest pieces to suit their own purposes,
0 historical approaches
1 =====================
0 # 2. historical approaches
21
32 Two of the earliest holistic computing systems, the Xerox Alto and Xerox Star, both developed at Xerox PARC and
43 introduced in the 70s and early 80s, pioneered not only graphical user-interfaces, but also the "Desktop Metaphor".
0 confusion
10 type_coercion_graph
21 tree_mmmfs
32 tree_mainstream
+0
-5
root/articles/mmmfs/mmmfs/confusion/text$markdown.md less more
0 For example, the difference between changing a file extension and converting a file between two formats is often unclear
1 to users, as evident from questions like this: <a
2 href="https://askubuntu.com/questions/166602/why-is-it-possible-to-convert-a-file-just-by-renaming-its-extension">
3 Why is it possible to convert a file just by renaming it?</a>, https://askubuntu.com/q/166602 from 2019-12-18
4 <!-- https://www.quora.com/What-happens-when-you-rename-a-jpg-to-a-png-file -->
0 mmmfs
1 =====
0 # 4. mmmfs
21
32 `mmmfs` is a newly developed personal data storage and processing system. It was developed first as a tool for
43 generating static websites, but has been extended with live interaction and introspection, as well as embedded
1211 The abstraction of data types is accomplished using two major components, the *Type System and Coercion Engine* and
1312 the *Fileder Unified Data Model* for unified data storage and access.
1413
15 ## the fileder unified data model
14 ## 4.1 the fileder unified data model
1615 The Fileder Model is the underlying unified data storage model.
1716 Like many data storage models it is based fundamentally on the concept of a hierarchical tree-structure.
1817
4140 It should be clear already from this short list that to mainstream operating systems, as well as the applications
4241 running on them, the format of a file is almost completely unknown and at best educated guesses can be made.
4342
44 <mmm-embed path="confusion" wrap="marginnote" style="margin-top: -3rem;"></mmm-embed>
4543 Because these various mechanisms are applied at different times by the operating system and applications, it is possible
4644 for files to be labelled or considered as being in different formats at the same time by different components of the
4745 system.
4846
49 This leads to confusion about the factual format of data among users, but can also pose a serious security risk:
47 This leads to confusion about the factual format of data among users<mmm-embed path="../references/renaming"
48 wrap="sidenote" style="margin-top: -3rem;">For example, the difference between changing a file extension and converting
49 a file between two formats is often unclear to users, as evident from questions like this: </mmm-embed>, but can
50 also pose a serious security risk:
5051 Under some circumstances it is possible that a file contains maliciously-crafted code and is treated as an executable
5152 by one software component, while a security mechanism meant to detect such code determines the same file to be a
52 legitimate image<mmm-embed path="../references/poc-or-gtfo" wrap="sidenote"></mmm-embed> (the file may in fact be valid
53 in both formats).
53 legitimate image<mmm-embed path="../references/poc-or-gtfo" wrap="sidenote" style="margin-top: 2rem"></mmm-embed>
54 (the file may in fact be valid in both formats).
5455
5556 In mmmfs, the example above might look like this instead:
5657 <mmm-embed path="tree_mmmfs">schematic view of an example mmmfs tree</mmm-embed>
7576 (recursively). Since *fileders* are the primary unit of data to be operated upon, *fileder* nesting emerges as a natural
7677 way of structuring complex data, both for access by the system and its components, as well as the user themself.
7778
78 ## the type system & coercion engine
79 ## 4.2 the type system & coercion engine
7980 As mentioned above, *facets* store data alongside its *type*, and when a component of the system requires data from a
8081 *fileder*, it has to specify the *expected type* (or a list of these) that it requires the data to be in. The system
8182 then attempts to coerce one of the existing facets into the *expected type*, if possible. This process can involve many
0 motivation
1 ==========
0 # 1. motivation
21
3 application-centric design
4 --------------------------
2 1.1 application-centric design
3 ------------------------------
54
65 The majority of users interact with modern computing systems in the form of smartphones, laptops or desktop PCs,
76 using the mainstream operating systems Apple iOS and Mac OS X, Microsoft Windows or Android.
4140 hide the way desktop operating systems work<mmm-embed path="../references/osx-files" wrap="sidenote"></mmm-embed>,
4241 mobile systems like Apple's *iOS* already started out as such *walled gardens*.
4342
44 cloud computing
45 ---------------
43 1.2 cloud computing
44 -------------------
4645
4746 *Web Apps* often offer similar functionality to other applications, but are subject to additional limitations:
4847 In most cases, they are only accessible or functional in the presence of a stable internet connection,
5958 consequences<mmm-embed path="../references/adobe" wrap="sidenote"></mmm-embed>, especially for professional users, for
6059 whom an inability to access their tools or their cloud-stored data can pose an existential threat.
6160
62 inert data (and data formats)
63 -----------------------------
61 1.3 inert data (and data formats)
62 ---------------------------------
6463
6564 Cragg coins the term "inert data"<mmm-embed path="../references/super-powers" wrap="sidenote"></mmm-embed> for the data
6665 created and left behind by apps and applications in the computing model that is currently prevalent: Most data today
8180 otherwise the user may have to remove the old image, insert the new one and carefully ensure that the positioning in
8281 the document remains intact.
8382
84 disjointed filesystems
85 ----------------------
83 1.4 disjointed filesystems
84 --------------------------
8685
8786 The filesystems and file models used on modern computing devices generally operate on the assumption that every
8887 individual file stands for itself. Grouping of files in folders is allowed as a convenience for users, but most
0 poc-or-gtfo
1 aspect-ratios
2 memex
03 appliances
1 osx-files
2 ios-files
34 super-powers
5 dijkstra
6 subtext
7 mime-types
8 alternatives-to-trees
9 xerox-star
10 unix
11 transclusion
412 adobe
5 xerox-star
6 memex
13 acm-dl
714 hypercard
8 wikipedia
9 unix
10 subtext
1115 inkandswitch
1216 linux-exec
13 poc-or-gtfo
14 acm-dl
15 aspect-ratios
16 alternatives-to-trees
17 transclusion
18 mime-types
19 dijkstra
17 wikipedia
18 osx-files
19 renaming
11 title = {Adobe is cutting off users in Venezuela due to US sanctions},
22 url = {https://www.theverge.com/2019/10/7/20904030/adobe-venezuela-photoshop-behance-us-sanctions},
33 publisher = {The Verge},
4 author = {Lee, Dami},
45 year = {2019},
56 visited = {2019-12-18},
67 }
+0
-6
root/articles/mmmfs/references/ios-files/text$bibtex less more
0 @online{ios:files,
1 title = {Use the Files app on your iPhone, iPad, or iPod touch},
2 url = {https://support.apple.com/en-us/HT206481},
3 publisher = {Apple},
4 visited = {2019-12-27},
5 }
0 @online{renaming,
1 title = {Why is it possible to convert a file just by renaming it?},
2 url = {https://askubuntu.com/q/166602},
3 publisher = {askubuntu.com},
4 visited = {2019-12-18},
5 }
44 refs = for ref in *@children
55 li ref\gett 'mmm/dom'
66 div {
7 h1 "references"
7 h1 "references", id: 'references'
88 ol with refs
99 refs.style = 'line-height': 'normal'
1010 }
00 <div class="print-only print-ownpage" style="margin: 4cm 0 0;">
1 <h1>Statement of Originality</h1>
1 <h1 id="statement">statement of originality</h1>
22 <p style="margin-top: 5cm">
33 This is to certify that the content of this project, documentation and thesis is my own work. It
44 has not been submitted for any other degree or other purposes. I certify that the intellectual
0 <!--
1 {
2 const fmt = x => `<a href="#${x.id}">${x.innerText}</a>`;
3
4 const parse = e => ({
5 num: +e.tagName.substr(1),
6 fmt: fmt(e),
7 });
8
9 const render = (list) => {
10 let str = '';
11 let num = 0;
12 for (e of list) {
13 while (e.num > num) {
14 str += '<ol style="list-style: none;">'
15 num += 1;
16 }
17
18 while (e.num < num) {
19 str += '</ol>';
20 num -= 1;
21 }
22
23 str += `<li>${e.fmt}</li>`;
24 }
25 return str;
26 };
27
28 render([...$0.querySelectorAll('h1, h2, h3, h4, h5').values()].map(parse));
29 }
30 -->
31 <section class="print-ownpage">
32 <h1 id="table-of-contents">table of contents</h1>
33 <ol style="list-style: none;">
34 <li><a href="#abstract">abstract</a></li>
35 <li><a href="#table-of-contents">table of contents</a></li>
36 <li><a href="#1-motivation">1. motivation</a></li>
37 <ol style="list-style: none;">
38 <li><a href="#11-application-centric-design">1.1 application-centric design</a></li>
39 <li><a href="#12-cloud-computing">1.2 cloud computing</a></li>
40 <li><a href="#13-inert-data-and-data-formats">1.3 inert data (and data formats)</a></li>
41 <li><a href="#14-disjointed-filesystems">1.4 disjointed filesystems</a></li>
42 </ol>
43 <li><a href="#2-historical-approaches">2. historical approaches</a></li>
44 <li><a href="#3-evaluation-framework">3. evaluation framework</a></li>
45 <ol style="list-style: none;">
46 <li><a href="#31-qualities-of-successful-end-user-computing">3.1 qualities of successful end-user computing</a></li>
47 <li><a href="#32-modularity">3.2 modularity</a></li>
48 <li><a href="#33-content-transclusion">3.3 content transclusion</a></li>
49 <li><a href="#34-end-user-programming">3.4 end-user programming</a></li>
50 </ol>
51 <li><a href="#4-mmmfs">4. mmmfs</a></li>
52 <ol style="list-style: none;">
53 <li><a href="#41-the-fileder-unified-data-model">4.1 the fileder unified data model</a></li>
54 <li><a href="#42-the-type-system--coercion-engine">4.2 the type system & coercion engine</a></li>
55 </ol>
56 <li><a href="#5-example-use-cases">5. example use-cases</a></li>
57 <ol style="list-style: none;">
58 <li><a href="#51-publishing-and-blogging">5.1 publishing and blogging</a></li>
59 <ol style="list-style: none;">
60 <li><a href="#511-blogging">5.1.1 blogging</a></li>
61 <li><a href="#512-scientific-publishing">5.1.2 scientific publishing</a></li>
62 </ol>
63 <li><a href="#52-pinwall">5.2 pinwall</a></li>
64 <li><a href="#53-slideshow">5.3 slideshow</a></li>
65 </ol>
66 <li><a href="#6-evaluation">6. evaluation</a></li>
67 <ol style="list-style: none;">
68 <li><a href="#61-examples">6.1 examples</a></li>
69 <ol style="list-style: none;">
70 <li><a href="#611-publishing-and-blogging">6.1.1 publishing and blogging</a></li>
71 <li><a href="#612-pinwall">6.1.2 pinwall</a></li>
72 <li><a href="#613-slideshow">6.1.3 slideshow</a></li>
73 </ol>
74 <li><a href="#62-general-concerns">6.2 general concerns</a></li>
75 <ol style="list-style: none;">
76 <li><a href="#621-global-set-of-converts">6.2.1 global set of converts</a></li>
77 <li><a href="#622-code-outside-of-the-system">6.2.2 code outside of the system</a></li>
78 <li><a href="#623-type-system">6.2.3 type system</a></li>
79 <li><a href="#624-type-coercion">6.2.4 type-coercion</a></li>
80 <li><a href="#625-in-system-editing">6.2.5 in-system editing</a></li>
81 </ol>
82 </ol>
83 <li><a href="#7-conclusion">7. conclusion</a></li>
84 <li><a href="#references">references</a></li>
85 <li><a href="#ba-log">appendix: project log</a></li>
86 <li><a href="#statement">statement of originality</a></li>
87 </ol>
88 </section>
1010 append = (a) -> table.insert _this, a
1111
1212 append div {
13 class: 'screen-only'
1413 h1 'Empowered End-User Computing', style: { 'margin-bottom': 0 }
1514 p {
1615 style: