table-of-contents, reference order
s-ol
2 years ago
103 | 103 | link_to fileder, node, nil, opts.attr |
104 | 104 | |
105 | 105 | when 'sidenote' |
106 | key = opts.desc or tostring refs\get! | |
106 | key = tostring refs\get! | |
107 | 107 | id = "sideref-#{key}" |
108 | 108 | |
109 | 109 | intext = sup a key, href: "##{id}" |
0 | 0 | title |
1 | 1 | abstract |
2 | table-of-contents | |
2 | 3 | motivation |
3 | 4 | historical-approaches |
4 | 5 | framework |
7 | 8 | evaluation |
8 | 9 | conclusion |
9 | 10 | references |
11 | ba_log | |
10 | 12 | 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). |
5 | 5 | div { |
6 | 6 | class: 'print-ownpage' |
7 | 7 | |
8 | h1 link_to @, "appendix: project log" | |
8 | h1 (link_to @, "appendix: project log"), id: 'ba-log' | |
9 | @gett 'intro: mmm/dom' | |
9 | 10 | table.unpack for post in *@children |
10 | 11 | continue if post\get 'hidden: bool' |
11 | 12 |
3 | 3 | |
4 | 4 | => |
5 | 5 | div { |
6 | h1 link_to @, "appendix: project log" | |
6 | h1 (link_to @, "appendix: project log"), id: 'ba-log' | |
7 | @gett 'intro: mmm/dom' | |
7 | 8 | ul do |
8 | 9 | posts = for post in *@children |
9 | 10 | continue if post\get 'hidden: bool' |
0 | conclusion | |
1 | ========== | |
0 | # 7. conclusion | |
2 | 1 | |
3 | 2 | <div class="well well-warning">[section under construction]</div> |
0 | evaluation | |
1 | ========== | |
0 | # 6. evaluation | |
2 | 1 | |
3 | ## examples | |
2 | ## 6.1 examples | |
4 | 3 | In this section I will take a look at the implementations of the example for the use cases outlined above, |
5 | 4 | and evaluate them with regard to the framework derived in the corresponding section above. |
6 | 5 | |
7 | ### publishing and blogging | |
6 | ### 6.1.1 publishing and blogging | |
8 | 7 | Since mmmfs has grown out of the need for a versatile CMS for a personal publishing website, it is not surprising to |
9 | 8 | see that it is still up to that job. Nevertheless it is worth taking a look at its strengths and weaknesses in this |
10 | 9 | context: |
24 | 23 | separately from its parent and context in most cases. This has made the implementation of sidenotes less idiomatic |
25 | 24 | than initially anticipated. |
26 | 25 | |
27 | ### pinwall | |
26 | ### 6.1.2 pinwall | |
28 | 27 | The pinwall example shows some strenghts of the mmmfs system pretty convincingly. |
29 | 28 | The type coercion layer completely abstracts away the complexities of transcluding different types of content, |
30 | 29 | and only positioning and sizing the content, as well as enabling interaction, remain to handle in the pinwall fileder. |
39 | 38 | UI layer (in this case the browser), which could feasibly be simplified through a custom abstraction layer or the use of |
40 | 39 | output means other than the web. |
41 | 40 | |
42 | ### slideshow | |
41 | ### 6.1.3 slideshow | |
43 | 42 | A simplified image slideshow example consists of only 20 lines of code and demonstrates how the reactive component |
44 | 43 | framework simplifies the generation of ad-hoc UI dramatically: |
45 | 44 | |
70 | 69 | The parts of the code dealing with the content are essentially identical, except that content is transcluded via the |
71 | 70 | more general `mmm/dom` type-interface, allowing for a greater variety of types of content to be used as slides. |
72 | 71 | |
73 | ## general concerns | |
72 | ## 6.2 general concerns | |
74 | 73 | While the system has proven pretty successful and moldable to the different use-cases that it has been tested in, |
75 | 74 | there are also limitations in the proposed system that have become obvious in developing and working with the system. |
76 | 75 | Some of these have been anticipated for some time and concrete research directions for solutions are apparent, |
77 | 76 | while others may be intrinsic limitations in the approach taken. |
78 | 77 | |
79 | ### global set of converts | |
78 | ### 6.2.1 global set of converts | |
80 | 79 | In the current system, there is only a single, global set of *converts* that can be potentially applied to facets |
81 | 80 | anywhere in the system. |
82 | 81 | Therefore it is necessary to encode behaviour directly (as code) in facets wherever exceptional behaviour is required. |
97 | 96 | The biggest downside to this approach would be that it presents another pressure factor for, while also reincforcing, |
98 | 97 | the hierarchical organization of data, thereby exacerbating the limits of hierarchical structures. |
99 | 98 | |
100 | ### code outside of the system | |
99 | ### 6.2.2 code outside of the system | |
101 | 100 | At the moment, a large part of the mmmfs codebase is still separate from the content, and developed outside of mmmfs |
102 | 101 | itself. This is a result of the development process of mmmfs and was necessary to start the project as the filesystem |
103 | 102 | itself matured, but has now become a limitation of the user experience: potential users of mmmfs would generally start |
114 | 113 | Both of these are expected to undergo changes as users adapt the system to their own content types and |
115 | 114 | domains of interest, as well as their visual identity, respectively. |
116 | 115 | |
117 | ### type system | |
116 | ### 6.2.3 type system | |
118 | 117 | The currently used type system based on strings and pattern matching has been largely satisfactory, |
119 | 118 | but has proven problematic for some anticipated use cases. |
120 | 119 | It should be considered to switch to a more intricate, |
126 | 125 | Using these mechanisms for example images could be requested with a maximum-resolution constraint to save on bandwidth |
127 | 126 | when embedded in other documents. |
128 | 127 | |
129 | ### type-coercion | |
128 | ### 6.2.4 type-coercion | |
130 | 129 | By giving the system more information about the data it is dealing with, |
131 | 130 | and then relying on the system to automatically transform between data-types, |
132 | 131 | it is easy to lose track of which format data is concretely stored in. |
141 | 140 | Emphasising the conversion process more strongly in this way might be a way to turn this feature from an opaque |
142 | 141 | hindrance into a transparent tool. This should represent a challenge mostly in terms of UX and UI design. |
143 | 142 | |
144 | ### editing | |
143 | ### 6.2.5 in-system editing | |
145 | 144 | Because many *converts* are not necessarily reversible, it is very hard to implement generic ways of editing stored data |
146 | 145 | in the same format it is viewed. For example, the system trivially converts markdown-formatted text sources into |
147 | 146 | 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 | |
1 | 1 | To illustrate the capabilities of the proposed system, and to compare the results with the framework introduced above, |
2 | 2 | a number of example use cases have been chosen and implemented from the perspective of a user. |
3 | 3 | In the following section I will introduce these use cases and briefly summarize the implementation |
4 | 4 | approach in terms of the capabilities of the proposed system. |
5 | 5 | |
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: |
30 | 30 | |
31 | 31 | li link_to child |
32 | 32 | |
33 | examples = div { | |
34 | style: | |
35 | position: 'relative' | |
36 | 'margin-top': '4rem' | |
33 | examples = ul for child in *@children | |
34 | preview child | |
37 | 35 | |
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 | |
2 | 1 | |
3 | 2 | In the following section, I will collect approaches and reviews of different end-user software systems from current |
4 | 3 | literature, as well as derive and present my own requirements and guiding principles for the development of a new |
5 | 4 | system. |
6 | 5 | |
7 | qualities | |
8 | --------- | |
6 | 3.1 qualities of successful end-user computing | |
7 | ---------------------------------------------- | |
9 | 8 | |
10 | 9 | *Ink and Switch* suggest three qualities for tools striving to support |
11 | 10 | end-user programming<mmm-embed path="../references/inkandswitch" wrap="sidenote"></mmm-embed>: |
25 | 24 | constraints: namely the construction of a system for end-users to keep, structure and display personal information and |
26 | 25 | thoughts. |
27 | 26 | |
28 | modularity | |
29 | ---------- | |
27 | 3.2 modularity | |
28 | -------------- | |
30 | 29 | |
31 | 30 | The *UNIX Philosophy*<mmm-embed path="../references/unix" wrap="sidenote"></mmm-embed> describes the software design |
32 | 31 | paradigm pioneered in the creation of the Unix operating system at the AT&T Bell Labs research center in the 1960s. The |
49 | 48 | Settling on a specific modular design model, and reifying other components of a system in terms of it, also corresponds |
50 | 49 | directly to the concept of *Embodiment* described by Ink & Switch. |
51 | 50 | |
52 | content transclusion | |
53 | -------------------- | |
51 | 3.3 content transclusion | |
52 | ------------------------ | |
54 | 53 | |
55 | 54 | The strengths of modular architectures should similarily extend also into the way the system will be used by users. |
56 | 55 | If users are to store their information and customized behaviour in such an architecture, then powerful tools need to be |
75 | 74 | storage conditions, with as little caveats as possible. In particular, the interactions of remote data access and |
76 | 75 | content transclusion should be paid attention to and taken into consideration for a system's design. |
77 | 76 | |
78 | end-user programming | |
79 | -------------------- | |
77 | 3.4 end-user programming | |
78 | ------------------------ | |
80 | 79 | |
81 | 80 | In order to provide users full access to their information as well as the computational infrastructure, |
82 | 81 | 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 | |
2 | 1 | |
3 | 2 | Two of the earliest holistic computing systems, the Xerox Alto and Xerox Star, both developed at Xerox PARC and |
4 | 3 | introduced in the 70s and early 80s, pioneered not only graphical user-interfaces, but also the "Desktop Metaphor". |
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 | |
2 | 1 | |
3 | 2 | `mmmfs` is a newly developed personal data storage and processing system. It was developed first as a tool for |
4 | 3 | generating static websites, but has been extended with live interaction and introspection, as well as embedded |
12 | 11 | The abstraction of data types is accomplished using two major components, the *Type System and Coercion Engine* and |
13 | 12 | the *Fileder Unified Data Model* for unified data storage and access. |
14 | 13 | |
15 | ## the fileder unified data model | |
14 | ## 4.1 the fileder unified data model | |
16 | 15 | The Fileder Model is the underlying unified data storage model. |
17 | 16 | Like many data storage models it is based fundamentally on the concept of a hierarchical tree-structure. |
18 | 17 | |
41 | 40 | It should be clear already from this short list that to mainstream operating systems, as well as the applications |
42 | 41 | running on them, the format of a file is almost completely unknown and at best educated guesses can be made. |
43 | 42 | |
44 | <mmm-embed path="confusion" wrap="marginnote" style="margin-top: -3rem;"></mmm-embed> | |
45 | 43 | Because these various mechanisms are applied at different times by the operating system and applications, it is possible |
46 | 44 | for files to be labelled or considered as being in different formats at the same time by different components of the |
47 | 45 | system. |
48 | 46 | |
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: | |
50 | 51 | Under some circumstances it is possible that a file contains maliciously-crafted code and is treated as an executable |
51 | 52 | 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). | |
54 | 55 | |
55 | 56 | In mmmfs, the example above might look like this instead: |
56 | 57 | <mmm-embed path="tree_mmmfs">schematic view of an example mmmfs tree</mmm-embed> |
75 | 76 | (recursively). Since *fileders* are the primary unit of data to be operated upon, *fileder* nesting emerges as a natural |
76 | 77 | way of structuring complex data, both for access by the system and its components, as well as the user themself. |
77 | 78 | |
78 | ## the type system & coercion engine | |
79 | ## 4.2 the type system & coercion engine | |
79 | 80 | As mentioned above, *facets* store data alongside its *type*, and when a component of the system requires data from a |
80 | 81 | *fileder*, it has to specify the *expected type* (or a list of these) that it requires the data to be in. The system |
81 | 82 | 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 | |
2 | 1 | |
3 | application-centric design | |
4 | -------------------------- | |
2 | 1.1 application-centric design | |
3 | ------------------------------ | |
5 | 4 | |
6 | 5 | The majority of users interact with modern computing systems in the form of smartphones, laptops or desktop PCs, |
7 | 6 | using the mainstream operating systems Apple iOS and Mac OS X, Microsoft Windows or Android. |
41 | 40 | hide the way desktop operating systems work<mmm-embed path="../references/osx-files" wrap="sidenote"></mmm-embed>, |
42 | 41 | mobile systems like Apple's *iOS* already started out as such *walled gardens*. |
43 | 42 | |
44 | cloud computing | |
45 | --------------- | |
43 | 1.2 cloud computing | |
44 | ------------------- | |
46 | 45 | |
47 | 46 | *Web Apps* often offer similar functionality to other applications, but are subject to additional limitations: |
48 | 47 | In most cases, they are only accessible or functional in the presence of a stable internet connection, |
59 | 58 | consequences<mmm-embed path="../references/adobe" wrap="sidenote"></mmm-embed>, especially for professional users, for |
60 | 59 | whom an inability to access their tools or their cloud-stored data can pose an existential threat. |
61 | 60 | |
62 | inert data (and data formats) | |
63 | ----------------------------- | |
61 | 1.3 inert data (and data formats) | |
62 | --------------------------------- | |
64 | 63 | |
65 | 64 | Cragg coins the term "inert data"<mmm-embed path="../references/super-powers" wrap="sidenote"></mmm-embed> for the data |
66 | 65 | created and left behind by apps and applications in the computing model that is currently prevalent: Most data today |
81 | 80 | otherwise the user may have to remove the old image, insert the new one and carefully ensure that the positioning in |
82 | 81 | the document remains intact. |
83 | 82 | |
84 | disjointed filesystems | |
85 | ---------------------- | |
83 | 1.4 disjointed filesystems | |
84 | -------------------------- | |
86 | 85 | |
87 | 86 | The filesystems and file models used on modern computing devices generally operate on the assumption that every |
88 | 87 | 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 | |
0 | 3 | appliances |
1 | osx-files | |
2 | ios-files | |
3 | 4 | super-powers |
5 | dijkstra | |
6 | subtext | |
7 | mime-types | |
8 | alternatives-to-trees | |
9 | xerox-star | |
10 | unix | |
11 | transclusion | |
4 | 12 | adobe |
5 | xerox-star | |
6 | memex | |
13 | acm-dl | |
7 | 14 | hypercard |
8 | wikipedia | |
9 | unix | |
10 | subtext | |
11 | 15 | inkandswitch |
12 | 16 | 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 |
1 | 1 | title = {Adobe is cutting off users in Venezuela due to US sanctions}, |
2 | 2 | url = {https://www.theverge.com/2019/10/7/20904030/adobe-venezuela-photoshop-behance-us-sanctions}, |
3 | 3 | publisher = {The Verge}, |
4 | author = {Lee, Dami}, | |
4 | 5 | year = {2019}, |
5 | 6 | visited = {2019-12-18}, |
6 | 7 | } |
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 | } |
4 | 4 | refs = for ref in *@children |
5 | 5 | li ref\gett 'mmm/dom' |
6 | 6 | div { |
7 | h1 "references" | |
7 | h1 "references", id: 'references' | |
8 | 8 | ol with refs |
9 | 9 | refs.style = 'line-height': 'normal' |
10 | 10 | } |
0 | 0 | <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> | |
2 | 2 | <p style="margin-top: 5cm"> |
3 | 3 | This is to certify that the content of this project, documentation and thesis is my own work. It |
4 | 4 | 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> |