git.s-ol.nu mmm / 3c03612
introduction s-ol 1 year, 9 months ago
20 changed file(s) with 272 addition(s) and 199 deletion(s). Raw diff Collapse all Expand all
00 title
11 abstract
22 table-of-contents
3 introduction
34 motivation
45 historical-approaches
56 framework
00 abstract
11 ========
22
3 <div class="well well-warning">[section under construction]</div>
3 Current end-user operating systems are based on a set of design principles and computing paradigms that make them
4 simple to use in some circumstances but are very inflexible for user customization and adaptation. In this thesis, these
5 limitations and design principles will be discussed and contrasted by an analysis of historic systems that solved these
6 issues by following different design goals. Based on this analysis, as well as further literature, an evaluation
7 framework for end-user computing systems is established.
8 The design and implementation of a new end-user computing system, which focuses on a file system with rich file types
9 and a type coercion system as its central paradigm, is discussed. Following this, the capabilities of the system are
10 demonstrated using multiple example use-cases. An evaluation of these examples as well as the system itself according
11 to the framework established earlier shows that the proposed system is indeed very flexible and useful for a wide
12 variety of uses involving multimedia content from various sources, although the system has many flaws that would hinder
13 widespread adoption.
55 div {
66 class: 'print-ownpage'
77
8 h1 (link_to @, "appendix: project log"), id: 'ba-log'
8 h1 (link_to @, "appendix: project log"), id: 'ba-log'
99 @gett 'intro: mmm/dom'
1010 table.unpack for post in *@children
1111 continue if post\get 'hidden: bool'
33
44 =>
55 div {
6 h1 (link_to @, "appendix: project log"), id: 'ba-log'
6 h1 (link_to @, "appendix: project log"), id: 'ba-log'
77 @gett 'intro: mmm/dom'
88 ul do
99 posts = for post in *@children
0 # 7. conclusion
0 # 8&emsp;conclusion
11
2 <div class="well well-warning">[section under construction]</div>
2 The historical analysis and the evaluation of the proposed system show that many of the limitations of current
3 mainstream operating systems can be worked around effectively. The flaws can also be attributed in part to some
4 concrete design paradigms, which future system designers may seek to avoid. To this end, the framework provided for
5 evaluation may also be useful.
36
4 In the beginning of this thesis multiple downsides of the most widely used end-user computing systems have been
5 demonstrated and attributed to an over-reliance on a set of design paradigms that do not align well with the goal of
6 empowering users. On the other hand, it has been shown that many well-recognized historic systems were designed with
7 this goal in mind.
8
9 Based on the aspirations and appraoches of these historic systems, a framework for the evaluation of empowering end-user
10 computing systems was developed alongside one such system itself. While the proposed system has been shown to have many
11 flaws and limitations of its own, and is not currently viable as a tool for end-users, it serves to demonstrate the
12 feasiblity of type coercion and the file system as a focus point for new end-user computing systems, and provides a
13 reference point for further research.
7 The system proposed and developed in the project corresponding to this thesis has been shown to successfully implement
8 many of the properties were hoped to be achieved, such as a modular and consistent architecture and strong support for
9 mixed-content transclusions. On the other hand, some limitations in the design are apparent. Many of these limitations
10 constitute candidate topics for further research, and most can be attributed to trade-offs made in the development process.
0 # 6. evaluation
1 In this section I will first take a look at the implementations of the examples for the use cases outlined above,
0 # 7&emsp;evaluation
1 In this section, I will first take a look at the implementations of the examples for the use cases outlined above,
22 and evaluate them with regard to the framework derived in the corresponding section above. After that, some general
33 concerns and insights that have become apparent while developing the system and working with it will be reviewed.
44
5 ## 6.1 examples
6 ### 6.1.1 publishing and blogging
7 Since mmmfs has grown out of the need for a versatile content-management system for a personal website and blog, it is
8 not surprising to see that it is still up to that job. Nevertheless it is worth taking a look at its strengths and
5 ## 7.1&emsp;examples
6 ### 7.1.1&emsp;publishing and blogging
7 Since mmmfs has grown out of the need for a versatile content management system for a personal website and blog, it is
8 not surprising to see that it is still up to that job. Nevertheless, it is worth taking a look at its strengths and
99 weaknesses in this context:
1010
1111 The system has proven itself perfect for publishing small- and medium-size articles and blog posts, especially for its
1919 This is mostly due to the approach of splitting up the thesis into a multitude of fileders, and the current lack of
2020 mechanisms to re-capture information spread throughout the resulting hierarchy effectively.
2121
22 ### 6.1.2 pinwall
22 ### 7.1.2&emsp;pinwall
2323 The pinwall example shows some strengths of the mmmfs system pretty convincingly.
2424 The type coercion layer completely abstracts away the complexities of transcluding different types of content,
2525 and only positioning and sizing the content, as well as enabling interaction, remain to handle in the pinwall fileder.
2626
27 A great benefit of the use of mmmfs versus other technology for realising this example is that the example can
27 A great benefit of the use of mmmfs versus other technology for realizing this example is that the example can
2828 seamlessly embed not only plain text, markdown, images, videos, and interactive widgets, but also follow links to all
2929 of these types of content, and display them meaningfully. Accomplishing this with traditional frameworks would take
3030 great effort, where mmmfs benefits from the reuse of these conversions across the whole system.
3434 UI layer (in this case the browser), which could feasibly be simplified through a custom abstraction layer or the use of
3535 output means other than the web.
3636
37 ### 6.1.3 slideshow
37 ### 7.1.3&emsp;slideshow
3838 A simplified image slideshow example consists of only 20 lines of code and demonstrates how the reactive component
3939 framework simplifies the generation of ad-hoc UI dramatically:
4040
6565 The parts of the code dealing with the content are essentially identical, except that content is transcluded via the
6666 more general `mmm/dom` type-interface, allowing for a greater variety of types of content to be used as slides.
6767
68 ## 6.2 general concerns
68 ## 7.2&emsp;general concerns
6969 While the system has proven pretty successful and moldable to the different use-cases that it has been tested in,
7070 there are also limitations in the proposed system that have become obvious in developing and working with the system.
71 In this section these limitations will be discussed individually, and directions for further research and solutions will
71 In this section, these limitations will be discussed individually, and directions for further research and solutions will
7272 be given where apparent.
7373
74 ### 6.2.1 global set of converts
74 ### 7.2.1&emsp;global set of converts
7575 In the current system, there is only a single, global set of *converts* that can be potentially applied to facets
7676 anywhere in the system.
77 Therefore it is necessary to encode behaviour directly (as code) in facets wherever exceptional behaviour is required.
78 For example if a fileder containing multiple images wants to provide custom UI for each image when viewed independently,
77 Therefore it is necessary to encode behavior directly (as code) in facets wherever exceptional behavior is required.
78 For example, if a fileder containing multiple images wants to provide custom UI for each image when viewed independently,
7979 this code has to either be attached to every image individually (and redundantly), or added as a global convert.
8080 To make sure this convert does not interfere with images elsewhere in the system, it would be necessary to introduce
8181 a new type and change the images to use it, which may present even more problems, and works against the principle of
8585 Application of *converts* could then be scoped to their fileders' subtrees, such that for any facet only the *converts*
8686 stored in the chain of its parents upwards are considered.
8787 This way, *converts* can be added locally if they only make sense within a given context.
88 Additionally it could be made possible to use this mechanism to locally override *converts* inherited from
89 further up in the tree, for example to specialize types based on their context in the system.
88 Additionally, it could be made possible to use this mechanism to locally override *converts* inherited from
89 further up in the tree, for example, to specialize types based on their context in the system.
9090
9191 <mmm-embed wrap="marginnote" path="../references/alternatives-to-trees">See also </mmm-embed>
9292 The biggest downside to this approach would be that it presents another pressure factor for, while also reinforcing,
9393 the hierarchical organization of data, thereby exacerbating the limits of hierarchical structures.
9494
95 ### 6.2.2 code outside of the system
96 At the moment, a large part of the mmmfs codebase is still separate from the content, and developed outside of mmmfs
95 ### 7.2.2&emsp;code outside of the system
96 At the moment, a large part of the mmmfs codebase is still separate from the content and developed outside of mmmfs
9797 itself. This is a result of the development process of mmmfs and was necessary to start the project as the filesystem
9898 itself matured, but has now become a limitation of the user experience: potential users of mmmfs would generally start
9999 by becoming familiar with the operation of mmmfs from within the system, as this is the expected (and designated)
103103 This weakness represents a failure to (fully) implement the quality of a "Living System" as proposed by
104104 *Ink and Switch*<mmm-embed path="../references/inkandswitch" wrap="sidenote"></mmm-embed>.
105105
106 In general however, some portion of code may always have to be left outside of the system.
106 In general, however, some portion of code may always have to be left outside of the system.
107107 This also wouldn't necessarily represent a problem, but in this case it is particularly relevant
108108 for the global set of *converts* (see above), as well as the layout used to render the web view.
109109 Both of these are expected to undergo changes as users adapt the system to their own content types and
110110 domains of interest, as well as their visual identity, respectively.
111111
112 ### 6.2.3 type system
113 The currently used type system based on strings and pattern matching has been largely satisfactory,
112 ### 7.2.3&emsp;type system
113 The currently used type system based on strings and pattern matching has been largely satisfactory
114114 but has proven problematic for some anticipated use cases.
115115 It should be considered to switch to a more intricate,
116116 structural type system that allows encoding more concrete meta-data alongside the type,
117117 and to match *converts* based on a more flexible scheme of pattern matching.
118 For example it is envisaged to store the resolution of an image file in its type.
118 For example, it is envisaged to store the resolution of an image file in its type.
119119 Many *converts* might choose to ignore this additional information,
120120 but others could use this information to generate lower-resolution 'thumbnails' of images automatically.
121121 Using these mechanisms for example images could be requested with a maximum-resolution constraint to save on bandwidth
122122 when embedded in other documents.
123123
124 ### 6.2.4 type-coercion
124 <div style="break-before: page;"></div>
125
126 ### 7.2.4&emsp;type-coercion
125127 By giving the system more information about the data it is dealing with,
126128 and then relying on the system to automatically transform between data-types,
127129 it is easy to lose track of which format data is concretely stored in.
133135
134136 Potential solutions could be to communicate the conversion path clearly and explicitly together with the content,
135137 as well as making this display interactive to encourage experimentation with custom conversion queries.
136 Emphasising the conversion process more strongly in this way might be a way to turn this feature from an opaque
138 Emphasizing the conversion process more strongly in this way might be a way to turn this feature from an opaque
137139 hindrance into a transparent tool. This should represent a challenge mostly in terms of UX and UI design.
138140
139 ### 6.2.5 in-system editing
141 ### 7.2.5&emsp;in-system editing
140142 Because many *converts* are not necessarily reversible, it is very hard to implement generic ways of editing stored data
141143 in the same format it is viewed. For example, the system trivially converts markdown-formatted text sources into
142144 viewable HTML markup, but it is hardly possible to propagate changes to the viewable HTML back to the markdown source.
155157
156158 As a result, interacting with the system at large is still a very different experience from editing content (and
157159 thereby extending the system) in it. This is expected to represent a major hurdle for users getting started with the
158 system, and is a major shortcoming in enabling end-user programming, as set as a goal for this project.
160 system and is a major shortcoming in enabling end-user programming, as set as a goal for this project.
159161 A future iteration should carefully reconsider how editing could be integrated more holistically with the other core
160162 concepts of the design.
163
164 <div style="break-before: page;"></div>
165
166 ### 7.2.6&emsp;end-user adoption
167 As mentioned above, a conscious choice was made to exclude the implementation of a dedicated end-user programming
168 facility in the system, and instead conventional programming languages and mechanisms were relied upon as the central
169 way of customizing the system and experience. While this was a crucial choice to make in order to proceed with the
170 project as a whole, it means that the system currently can not be adopted and used to its full extent by
171 end-users. This also means that a full evaluation of the system with regard to end-user empowerment has to be left open
172 until this can be changed by further work.
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,
0 ## 6.1&emsp;publishing and blogging
1 ### 6.1.1&emsp;blogging
2 Blogging is pretty straightforward since it generally just involves publishing lightly-formatted text,
33 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:
4 Markdown is a great tool for this job, and has been integrated into the system to much success:
55 There are two different types registered with *converts*: `text/markdown` and `text/markdown+span`.
66 They both render to HTML (and DOM nodes), so they are immediately viewable as part of the system.
77 The only difference for `text/markdown+span` is that it is limited to a single line,
88 and doesn't render as a paragraph but rather just a line of text.
99 This makes it suitable for denoting formatted-text titles and other small strings of text.
1010
11 The problem of embedding other content together with text comfortably is also solved easily,
11 The problem of embedding other content together with text comfortably is also solved easily
1212 because Markdown allows embedding arbitrary HTML in the document.
1313 This made it possible to define a set of pseudo-HTML elements in the Markdown-convert,
1414 `<mmm-embed>` and `<mmm-link>`, which respectively embed and link to other content native to mmmfs.
1515
16 ### 5.1.2 academic publishing
16 ### 6.1.2&emsp;academic publishing
1717 <div class="sidenote" style="margin-top: 1.25rem">
1818 One of the 'standard' solutions, <a href="https://www.latex-project.org/">LaTeX</a>,
1919 is arguably at least as complex as the mmm system proposed here, but has a much narrower scope,
2121 </div>
2222
2323 Academic 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
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
2626 systems and media to do work for the writer.
2727
2828 One such topic is the topic of references.
29 References appear in various formats at multiple positions in a academic document;
30 usually they are referenced via a reduced visual form within the text of the document,
29 References appear in various formats at multiple positions in an academic document;
30 usually, they are referenced via a reduced visual form within the text of the document
3131 and then shown again with full details at the end of the document.
3232
3333 For the sake of this thesis, referencing has been implemented using a subset of the popular
4141 ACM DL entry in mmmfs, and the reference will automatically be fetched, and therefore stay up to date with potential
4242 remote corrections.
4343
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 spatially so that they can be viewed
47 at a glance or organized into different contexts etc.
44 ## 6.2&emsp;pinwall
45 In many situations, and particularly for creative work, it is often useful to compile resources of
46 different types for reference or inspiration and arrange them spatially so that they can be viewed
47 at a glance or organized into different contexts, etc.
4848 Such a pinwall could serve for example to organize references to articles,
49 to collect visual inspiration for a moodboard etc.
49 to collect visual inspiration for a mood board, etc.
5050
5151 As a collection, the Pinwall is primarily mapped to a Fileder in the system.
5252 Any content that is placed within can then be rendered by the Pinwall,
5353 which can constrain every piece of content to a rectangular piece on its canvas.
5454 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,
55 which enumerates the list of children, wraps each in such a rectangular container
5656 and outputs the list of containers as DOM elements.
5757
5858 The position and size of each panel are stored in an ad-hoc facet, encoded in the JSON data format:
6565 Whenever a change is made the event handler can then update the value in the `pinwall_info` facet,
6666 so that the updated position and size are stored for the next time the pinwall is opened.
6767
68 ## 5.3 slideshow
68 ## 6.3&emsp;slideshow
6969 Another common use of digital documents is as aids in a verbal presentation.
7070 These often take the form of slideshows, for the creation of which a number of established applications exist.
7171 In simple terms, a slideshow is simply a linear series of screen-sized documents, that can be
7878 of the website that may distract from the presentation, and register an event handler for keyboard accelerators
7979 for moving through the presentation.
8080
81 Finally the script simply embeds the first of its child-fileders into the viewport rectangle.
81 Finally, the script simply embeds the first of its child-fileders into the viewport rectangle.
8282 Once the current slide is changed, the next embedded child is simply chosen.
8383
8484 <!--
0 # 5. example use-cases
0 # 6&emsp;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 <div style="break-before: page;"></div>
7
68 <span class="sidenote">The online version is available at [s-ol.nu/ba](https://s-ol.nu/ba).</span>
79 The following examples can be viewed and inspected in the interactive version online:
3333 examples = ul for child in *@children
3434 preview child
3535
36 div (@gett 'intro: mmm/dom'), examples, (@gett 'implementation: mmm/dom')
36 div {
37 style:
38 'break-after': 'page'
39
40 (@gett 'intro: mmm/dom')
41 examples
42 (@gett 'implementation: mmm/dom')
43 }
0 # 3. evaluation framework
0 # 4&emsp;evaluation framework
11
22 In this section, I will collect approaches and reviews of different end-user software systems from current literature,
33 as well as derive and present my own requirements and guiding principles for the development of a new system.
55 Firstly, I will take a look at a framework for evaluating end-user computing systems from literature, before presenting
66 three concrete design principles and components for a new system.
77
8 3.1 qualities of successful end-user computing
9 ----------------------------------------------
8 4.1&emsp;qualities of successful end-user computing
9 ---------------------------------------------------
1010
11 *Ink and Switch* suggest three qualities for tools striving to support
12 end-user programming<mmm-embed path="../references/inkandswitch" wrap="sidenote"></mmm-embed>:
11 *Ink and Switch* suggest three qualities for tools striving to support <span style="display: inline-block;">
12 end-user programming<mmm-embed path="../references/inkandswitch" wrap="sidenote"></mmm-embed>:</span>
1313
1414 - *Embodiment*, i.e. reifying central concepts of the programming model as more concrete, tangible objects
15 in the digital space (for example through visual representation),
15 in the digital space (for example, through visual representation),
1616 in order to reduce cognitive load on the user.
1717 - *Living System*, by which they seem to describe the malleability of a system or environment,
1818 and in particular the ability to make changes at different levels of depth in the system with
2121 as well as a certain accessibility of these tools, granted by a conceptual affinity between the
2222 use of the tools and general 'passive' use of containing system at large.
2323
24 These serve as guiding principles for the design and evaluation of computer systems for end-users, but are by nature
24 These serve as guiding principles for the design and evaluation of computer systems for end-users but are by nature
2525 very abstract. The following properties are therefore derived as more concrete proposals based on more specific
2626 constraints: namely the construction of a system for end-users to keep, structure and display personal information and
2727 thoughts.
2828
29 3.2 modularity
30 --------------
29 <div style="break-after: page;"></div>
30
31 4.2&emsp;modularity
32 -------------------
3133
3234 The *UNIX Philosophy*<mmm-embed path="../references/unix" wrap="sidenote"></mmm-embed> describes the software design
3335 paradigm pioneered in the creation of the Unix operating system at the AT&T Bell Labs research center in the 1960s. The
5153 Settling on a specific modular design model, and reifying other components of a system in terms of it, also corresponds
5254 directly to the concept of *Embodiment* described by Ink & Switch.
5355
54 3.3 content transclusion
55 ------------------------
56 4.3&emsp;content transclusion
57 -----------------------------
5658
5759 The strengths of modular architectures should similarly extend also into the way the system will be used by users.
58 If users are to store their information and customized behaviour in such an architecture, then powerful tools need to be
60 If users are to store their information and customized behavior in such an architecture, then powerful tools need to be
5961 present in order to assemble more complex solutions out of such parts. Therefore static content should be able to be
6062 linked to (as envisioned for the *Memex*, see above), but also to be <mmm-embed wrap="marginnote"
6163 path="../references/transclusion">The term <i>transclusion</i> refers to the concept of including content from a
6264 separate document, possibly stored remotely, by reference rather than by duplication. See also
6365 </mmm-embed>*transcluded*,
6466 to facilitate the creation of flexible data formats and interactions, such that e.g. a slideshow slide can include
65 content in a variety other formats (such as images and text) from anywhere else in the system. Behaviours also should be
67 content in a variety other formats (such as images and text) from anywhere else in the system. Behaviors also should be
6668 able to be transcluded and reused to facilitate the creation of ad-hoc systems and applets based on user needs. For
67 example a user-created todo list should be able to take advantage of a sketching tool the user already has access to.
69 example, a user-created todo list should be able to take advantage of a sketching tool the user already has access to.
6870
6971 By forming the immediately user-visible layer of the system out of the same abstractions that the deeper levels of the
7072 system are made of, the sense of a *Living System* is also improved: skills that are learned at one (lower) level of the
7274 system's mechanisms.
7375
7476 While there are drawbacks to cloud-storage of data (as outlined above), the utility of distributed systems is
75 acknowledged, and the system should therefore be able to include content and behaviours via the network.
77 acknowledged, and the system should therefore be able to include content and behaviors via the network.
7678 This ability should be integrated deeply into the system, so that data can be treated independently of its origin and
7779 storage conditions, with as little caveats as possible. In particular, the interactions of remote data access and
7880 content transclusion should be paid attention to and taken into consideration for a system's design.
7981
80 3.4 end-user programming
81 ------------------------
82 4.4&emsp;end-user programming
83 -----------------------------
8284
8385 In order to provide users full access to their information as well as the computational infrastructure,
8486 users need to be able to finely customize and reorganize the smallest pieces to suit their own purposes,
8587 in other words: be able to program.
8688
8789 While there is an ongoing area of research focusing on the development of new programming paradigms,
88 methodologies and tools that are more accessible and cater to the wide
90 methodologies, and tools that are more accessible and cater to the wide
8991 range of end-users<mmm-embed path="../references/subtext" wrap="sidenote"></mmm-embed>,
9092 in order to keep the scope of this work appropriate,
9193 conventional programming languages are used for the time being.
0 # 2. historical approaches
0 <div style="break-before: page;"></div>
1
2 # 3&emsp;historical approaches
13
24 Two of the earliest holistic computing systems, the Xerox Alto and Xerox Star, both developed at Xerox PARC and
3 introduced in the 70s and early 80s, pioneered not only graphical user-interfaces, but also the "Desktop Metaphor".
5 introduced in the 70s and early 80s pioneered not only graphical user-interfaces but also the "Desktop Metaphor".
46 The desktop metaphor presents information as stored in "Documents" that can be organized in folders and on the
57 "Desktop". It invokes a strong analogy to physical tools. One of the differences between the Xerox Star system and
68 other systems at the time, as well as the systems we use currently, is that the type of data a file represents is
79 directly known to the system.
810
9 In a retrospective analysis of the Xerox Star's impact on the computer
10 industry, the desktop metaphor is described as
11 In a retrospective analysis of the Xerox Star's impact on the computer industry, the desktop metaphor is described as
1112 follows:
1213
1314 <mmm-embed path="../references/xerox-star" wrap="marginnote"></mmm-embed>
2122 > this disadvantage.
2223
2324 Other systems at the time lacked any knowledge of the type of files, and while mainstream operating systems of today
24 have retro-fit the ability to associate and memorize the preferred applications to use for a given file based on it's
25 have retro-fit the ability to associate and memorize the preferred applications to use for a given file based on its
2526 name suffix, the intention of making applications a secondary, technical detail of working with the computer has
2627 surely been lost.
2728
2829 Another design detail of the Star system is the concept of "properties" that are stored for "objects" throughout the
2930 system (the objects being anything from files to characters or paragraphs). These typed pieces of information are
30 labelled with a name and persistently stored, providing a mechanism to store metadata such as user preference for
31 labeled with a name and persistently stored, providing a mechanism to store metadata such as user preference for
3132 ordering or the default view mode of a folder for example.
33
34 The earliest indirect influence for the Xerox Alto and many other systems of its time was the *Memex*.
35 The *Memex* is a hypothetical device and system for knowledge management. Proposed by Vannevar Bush in 1945<mmm-embed
36 path="../references/memex" wrap="sidenote"></mmm-embed>, the concept predates much of the technology that later was used
37 to implement many parts of the vision.
3238
3339 <mmm-embed path="star-graph" facet="note" wrap="marginnote" style="margin-top: 1rem;"></mmm-embed>
3440 <mmm-embed path="star-graph" nolink></mmm-embed>
35
36 The earliest indirect influence for the Xerox Alto and many other systems of its time, was the *Memex*.
37 The *Memex* is a hypothetical device and system for knowledge management. Proposed by Vannevar Bush in 1945<mmm-embed
38 path="../references/memex" wrap="sidenote"></mmm-embed>, the concept predates much of the technology that later was used
39 to implement many parts of the vision.
4041
4142 <!--
4243 While the article extrapolates from existing technology at the time, describing at times
5152 feasible and a proven concept (exemplified for example by the massively successful online encyclopedia
5253 *Wikipedia*<mmm-embed path="../references/wikipedia" wrap="sidenote"></mmm-embed>).
5354
54 While there are little such tools available today, one of the systems that could be said to have come closest to a
55 While there are few such tools available today, one of the systems that could be said to have come closest to a
5556 practical implementation of a Memex-inspired system for personal use might be Apple's *HyperCard*.
5657
5758 In a live demonstration<mmm-embed path="../references/hypercard" wrap="sidenote"></mmm-embed>, the creators of the
5859 software showcase a system of stacks of cards that together implement, amongst others, a calendar (with yearly and
5960 weekly views), a list of digital business cards for storing phone numbers and addresses, and a todo list. However these
6061 stacks of cards are not just usable by themselves, it is also demonstrated how stacks can link to each other in
61 meaningful ways, such as jumping to the card corresponding to a specific day from the yearly calendar view, or
62 meaningful ways, such as jumping to the card corresponding to a specific day from the yearly calendar view or
6263 automatically looking up the card corresponding to a person's first name from a mention of the name in the text on a
6364 different card.
6465
6566 Alongside Spreadsheets, *HyperCard* remains one of the most successful implementations of end-user programming, even
6667 today. While its technical abilities have been long matched and surpassed by other software (such as the ubiquitous
67 *Hypertext Markup Language*, HTML and the associated programming language *JavaScript*), these technical successors have
68 *Hypertext Markup Language* HTML, and the associated programming language *JavaScript*), these technical successors have
6869 failed the legacy of *HyperCard* as an end-user tool: While it is easier than ever to publish content on the web
6970 (through various social media and microblogging services), the benefits of hypermedia as a customizable medium for
7071 personal management have nearly vanished. End-users do not create hypertext anymore.
72
0 1&emsp;introduction
1 ====================
2
3 As of December 2019, there are only four major operating systems available to end-users for desktop and mobile
4 devices<mmm-embed path="../references/market-share" wrap="sidenote"></mmm-embed>. All of these systems are comparatively inflexible and
5 can only be customized by users where the system or application developers have anticipated a need with corresponding
6 options. Only a small minority of professional or hobby developers have the knowledge and tools at their disposal to
7 create their own digital experiences, and even for them, the process is often too complex and inefficient to do so
8 effectively.
9 However, historically, empowered ownership of the computing experience was not meant to be restricted only to
10 end-users. Many computing systems designed during the computer revolution were designed specifically with the goal of
11 complete customizability by users, but little of this approach remains in the systems we use today.
12
13 In the first section of this thesis, I will discuss some of the limitations of mainstream operating systems and
14 potential causes in detail. Next, I will highlight some of the contrasting approaches found in historic computing
15 systems, and then derive a framework for the evaluation of end-user computing systems with regard to user empowerment.
16 I will then discuss a new computing system, demonstrate it in some example use cases, and evaluate it using the
17 framework.
0 # 4. system description
0 # 5&emsp;system description
11
2 Alongside this thesis a new end-user computing system has been developed together with the framework presented above.
2 Alongside this thesis, a new end-user computing system has been developed together with the framework presented above.
33 The system, `mmmfs`, is a personal data storage and processing system that was initially developed as a tool for
4 generating static websites, but has now been extended with capabilities for live interaction and introspection, as well
4 generating static websites but has now been extended with capabilities for live interaction and introspection, as well
55 as embedded editing, as part of this work.
66
77 mmmfs has been designed with a focus on data ownership for users. One of the main driving ideas is to unlock data
88 from external data silos and file formats by making data available uniformly across different storage systems and
9 formats. Secondly, computation and interactive elements are also integrated in this paradigm, so that mmmfs can be
9 formats. Secondly, computation and interactive elements are also integrated into this paradigm, so that mmmfs can be
1010 seamlessly extended and molded to the user's needs.
1111
1212 The abstraction of data types is accomplished using two major components, the *Type System and Coercion Engine* and
13 the *Fileder Unified Data Model* for unified data storage and access. In the next sections the design and implementation
14 of these two components will be described in detail.
13 the *Fileder Unified Data Model* for unified data storage and access. In the next sections, the design and
14 implementation of these two components will be described in detail.
1515
16 ## 4.1 data storage model
16 ## 5.1&emsp;data storage model
1717 The Fileder Model is the underlying unified data storage model.
1818 Like many data storage models it is based fundamentally on the concept of a hierarchical tree-structure.
1919
2525 perspective, mostly opaque and inert blocks of data.
2626
2727 Some metadata, such as file size and access permissions, is associated with each file,
28 but notably the type of data is generally not actually stored in the filesystem,
28 but notably, the type of data is generally not actually stored in the filesystem,
2929 but determined loosely based on multiple heuristics depending on the system and context.
30 Some notable mechanism are:
30 Some notable mechanisms are:
3131
3232 - Suffixes at the end of the filename are often used to indicate which kind of data a file contains. However there is no
3333 centralized standardization of suffixes, and often one suffix is used for multiple incompatible versions of a
3434 file-formats, or multiple suffixes are used interchangeably for one format.
3535 - Many file-formats specify a specific data-pattern either at the very beginning or very end of a given file.
36 On unix systems the `libmagic` database and library of these so-called *magic constants* is commonly used to guess
36 On UNIX systems the `libmagic` database and library of these so-called *magic constants* is commonly used to guess
3737 the file-type based on these fragments of data.
3838 - on UNIX systems, files to be executed are checked by a variety of methods<mmm-embed path="../references/linux-exec"
3939 wrap="sidenote"></mmm-embed> in order to determine which format would fit. For example, script files, the "shebang"
4040 symbol, `#!`, can be used to specify the program that should parse this file in the first line of the file.
4141
4242 It should be clear already from this short list that to mainstream operating systems, as well as the applications
43 running on them, the format of a file is almost completely unknown and at best educated guesses can be made.
43 running on them, the format of a file is almost completely unknown and, at best, educated guesses can be made.
4444
4545 Because these various mechanisms are applied at different times by the operating system and applications, it is possible
46 for files to be labelled or considered as being in different formats at the same time by different components of the
46 for files to be labeled or considered as being in different formats at the same time by different components of the
4747 system.
4848
4949 This leads to confusion about the factual format of data among users<mmm-embed path="../references/renaming"
5050 wrap="sidenote" style="margin-top: -3rem;">For example, the difference between changing a file extension and converting
5151 a file between two formats is often unclear to users, as evident from questions like this: </mmm-embed>, but can
5252 also pose a serious security risk:
53 Under some circumstances it is possible that a file contains maliciously-crafted code and is treated as an executable
53 Under some circumstances, it is possible that a file contains maliciously-crafted code and is treated as an executable
5454 by one software component, while a security mechanism meant to detect such code determines the same file to be a
5555 legitimate image<mmm-embed path="../references/poc-or-gtfo" wrap="sidenote" style="margin-top: 2rem"></mmm-embed>
5656 (the file may in fact be valid in both formats).
5858 In mmmfs, the example above might look like this instead:
5959 <mmm-embed path="tree_mmmfs">schematic view of an example mmmfs tree</mmm-embed>
6060
61 Superficially, this may look quite similar: there is still only two types of nodes (referred to as *fileders* and
61 Superficially, this may look quite similar: there are still only two types of nodes (referred to as *fileders* and
6262 *facets*), and again one of them, the *fileders* are used only to hierarchically organize *facets*. Unlike *files*,
6363 *facets* don't only store a freeform *name*, there is also a dedicated *type* field associated with every *facet*, that
6464 is explicitly designed to be understood and used by the system.
6969
7070 In mmmfs, a *facet* should only ever be considered an aspect of its *fileder*, and never as separate from it.
7171 A *fileder* can contain multiple *facets*, but they are meant to be alternate or equivalent representations of the
72 *fileder* itself. Though for some uses it is required, software in general does not have to be directly aware of the
72 *fileder* itself. Though for some uses it is required, software generally does not have to be directly aware of the
7373 *facets* existing within a *fileder*, rather it assumes the presence of content in the representation that it requires,
7474 and simple requests it. The *Type Coercion Engine* (see below) will then attempt to satisfy this request based on the
7575 *facets* that are in fact present.
7878 (recursively). Since *fileders* are the primary unit of data to be operated upon, *fileder* nesting emerges as a natural
7979 way of structuring complex data, both for access by the system and its components, as well as the user themself.
8080
81 ## 4.2 type system and coercion engine
81 <div style="break-after: page;"></div>
82
83 ## 5.2&emsp;type system and coercion engine
8284 As mentioned above, *facets* store data alongside its *type*, and when a component of the system requires data from a
8385 *fileder*, it has to specify the *expected type* (or a list of these) that it requires the data to be in. The system
8486 then attempts to coerce one of the existing facets into the *expected type*, if possible. This process can involve many
9698 - `image/png`
9799 - `image/jpeg`
98100
99 While these types allow some amount of specificity, they fall short of describing their content especially in cases where
100 formats overlap: Source code for example is often distributed in `.tar.gz` archive files (directory-trees that are first
101 bundled into an `application/x-tar` archive, and then compressed into an `application/gzip` archive). Using either of
102 these two types is respectively incorrect or insufficient information to properly treat and extract the contained data.
101 While these types allow some amount of specificity, they fall short of describing their content especially in cases
102 where formats overlap: Source code, for example, is often distributed in `.tar.gz` archive files (directory-trees that
103 are first bundled into an `application/x-tar` archive, and then compressed into an `application/gzip` archive). Using
104 either of these two types is respectively incorrect or insufficient information to properly treat and extract the
105 contained data.
103106
104107 To mitigate this problem, mmmfs *types* can be nested. This is denoted in mmmfs *type* strings using the `->` symbol,
105108 e.g. the mmmfs *types* `application/gzip -> application/tar -> dirtree` and `URL -> image/jpeg` describe a
106109 tar-gz-compressed directory tree and the URL linking to a JPEG-encoded picture respectively.
107110
108111 Depending on the outer type this nesting can mean different things:
109 for URLs the nested type is expected to be found after fetching the URL with HTTP,
112 for URLs, the nested type is expected to be found after fetching the URL with HTTP,
110113 compression formats are expected to contain contents of the nested types,
111114 and executable formats are expected to output data of the nested type.
112115
113116 It is a lot more important to be able to accurately describe the type of a *facet* in mmmfs than in mainstream operating
114 systems, because while in the latter types are mostly used only associate an application that will then prompt the user
117 systems because while in the latter types are mostly used only associate an application that will then prompt the user
115118 for further steps if necessary, mmmfs uses the *type* to automatically find one or more programs to execute, in order to
116119 convert or transform the data stored in a *facet* into the *type* required in the context where it was requested.
117120
118121 This process of *type coercion* uses a database of known *converts* that can be applied to data. Every *convert*
119122 consists of a description of the input *types* that it can accept, the output *type* it would produce for a given input
120123 type, as well as the code for actually converting a given piece of data. Simple *converts* may simply consist of a fixed
121 in and output type, such as for example this *convert* for rendering Markdown-encoded text to a HTML hypertext fragment:
124 in and output type, such as this *convert* for rendering Markdown-encoded text to an HTML hypertext fragment:
122125
123126 {
124127 inp: 'text/markdown'
127130 -- implementation stripped for brevity
128131 }
129132
130 Other *converts* on the other hand may accept a wide range of input types:
133 Other *converts*, on the other hand, may accept a wide range of input types:
131134
132135 {
133136 inp: 'URL -> image/.*'
167170 roughly estimate both the cost (in terms of computing power) of the conversion, as well as the accuracy or immediacy of
168171 the conversion. For example, resizing an image to a lower size should have a high cost, because the process is
169172 computationally expensive, but also because a smaller image represents the original image to a lesser degree.
170 Similarly, an URL to a piece of content is a less immediate representation than the content itself, so the cost of a
173 Similarly, a URL to a piece of content is a less immediate representation than the content itself, so the cost of a
171174 *convert* that simply generates the URL to a piece of data should be high even if the process is very cheap to compute.
172175
173176 Cost is defined in this way to make sure that the result of a type-coercion operation reflects the content that was
184187 in this way. All *types* found that have not yet been inserted into the set of given *types* are then added to the
185188 set, so that they may be searched as well.
186189
187 The algorithm doesn't stop immediately after reaching a *type* from the result set, it continues search until it either
188 completely exhausts the result space, or until all non-exhaustively searched paths already have costs higher than the
189 allowed maximum. This ensures that the optimal path is found, even if a more expensive path is found more quickly
190 The algorithm doesn't stop immediately after reaching a *type* from the result set, it continues to search until it
191 either completely exhausts the result-space, or until all non-exhaustively searched paths already have costs higher than
192 the allowed maximum. This ensures that the optimal path is found, even if a more expensive path is found more quickly
190193 initially.
191194
192195 <mmm-embed path="type_coercion_graph">excerpt of the graph of conversion paths from two starting facets to mmm/dom
0 # 1. motivation
0 # 2&emsp;drawbacks of current systems
11
2 The project that this thesis accompanies was created out of a frustration with the computing systems that are currently
2 The project that this thesis accompanies was created out of frustration with the computing systems that are currently
33 popular and widely available to end-users. The following sections document and exemplify the perceived shortcomings that
44 these systems exhibit, as attributed to specific concepts or paradigms that the systems seem to be designed around.
55
6 1.1 application-centric design
7 ------------------------------
6 2.1&emsp;application-centric design
7 -----------------------------------
88
99 The majority of users interact with modern computing systems in the form of smartphones, laptops or desktop PCs,
1010 using the mainstream operating systems Apple iOS and Mac&nbsp;OS&nbsp;X, Microsoft&nbsp;Windows or Android.
1111
1212 <mmm-embed path="app-types" wrap="marginnote"></mmm-embed>
1313 All of these operating systems share the concept of *Applications* (or *Apps*) as one of the core pieces of their
14 interaction model. Functionality and capabilities of the digital devices are bundled in, marketed, sold and distributed
14 interaction model. The functionality and capabilities of digital devices are bundled, marketed, sold and distributed
1515 as applications. This focus on applications as the primary unit of systems can be seen as the root cause of multiple
1616 problems.
1717
2121 path="../references/appliances"></mmm-embed>. This makes many software packages more complex and unintuitive than
2222 they need to be, and also cripples interoperability between applications and data formats.
2323
24 Because (private) software developers are incentivised to keep customers, they make use of network effects to keep
24 Because (private) software developers are incentivized to keep customers, they make use of network effects to keep
2525 customers locked-in. This often means re-implementing services and functionality that is already available to users,
26 and integrating it directly in other applications or as a new product by the same organisation.
26 and integrating it directly in other applications or as a new product by the same organization.
2727 While this strategy helps big software companies retain customers, it harms users, who have to navigate a complex
28 landscape of multiple incompatible, overlapping and competing software ecosystems.
29 Data of the same kind, a rich-text document for example, can be shared easily within the software systems of a certain
28 landscape of multiple incompatible, overlapping, and competing software ecosystems.
29 Data of the same kind, a rich-text document, for example, can be shared easily within the software systems of a certain
3030 manufacturer and with other users of the same, but sharing with users of a competing system, even if it has almost the
31 exact same capabilities, can often be problematic.
31 same capabilities, can often be problematic<mmm-embed path="../references/lock-in" wrap="sidenote"></mmm-embed>.
3232
33 Another issue is that due to the technical challenges of development in the this paradigm, applications are designed and
33 Another issue is that due to the technical challenges of development in this paradigm, applications are designed and
3434 developed by experts in application development, rather than experts in the domain of the tool. While developers may
3535 solicit feedback, advice, and ideas from domain experts, communication is a barrier. Additionally, domain experts are
3636 generally unfamiliar with the technical possibilities, and may therefore not be able to express feedback that would lead
3939 As a result, creative use of computer technology is limited to programmers, since applications constrain their users to
4040 the paths and abilities that the developers anticipated and deemed useful.
4141
42 The application-centric computing metaphor treats applications as black boxes, and provides no means to understand,
43 customize or modify the behaviour of apps, intentionally obscuring the inner-workings of applications and
42 The application-centric computing metaphor treats applications as black boxes and provides no means to understand,
43 customize or modify the behavior of apps, intentionally obscuring the inner-workings of applications and
4444 completely cutting users off from this type of ownership over their technology. While the trend seems to be to further
4545 hide the way desktop operating systems work<mmm-embed path="../references/osx-files" wrap="sidenote"></mmm-embed>,
46 mobile systems like Apple's *iOS* already started out as such *walled gardens*.
46 mobile systems like Apple's *iOS* were designed as such *walled gardens* from the start.
4747
48 1.2 cloud computing
49 -------------------
48 2.2&emsp;cloud computing
49 ------------------------
5050
51 *Web Apps* often offer similar functionality to other applications, but are subject to additional limitations:
51 *Web Apps* often offer similar functionality to other applications but are subject to additional limitations:
5252 In most cases, they are only accessible or functional in the presence of a stable internet connection,
5353 and they have very limited access to the resources of the physical computer they are running on.
5454 For example, they usually cannot interact directly with the file system, hardware peripherals or other applications,
5656 video from a webcam, opening another website).
5757
5858 Cloud software, as well as subscription-model software with online-verification mechanisms, are additionally subject
59 to license changes, updates modifying, restricting or simply removing past functionality etc. Additionally, many cloud
59 to license changes, updates modifying, restricting or simply removing past functionality, etc. Additionally, many cloud
6060 software solutions and ecosystems store the users' data in the cloud, often across national borders, where legal and
6161 privacy concerns are intransparently handled by the companies. If a company, for any reason, is unable or unwilling to
62 continue servicing a customer, the users data may be irrecoverably lost (or access prevented). This can have serious
62 continue servicing a customer, the user's data may be irrecoverably lost (or access prevented). This can have serious
6363 consequences<mmm-embed path="../references/adobe" wrap="sidenote"></mmm-embed>, especially for professional users, for
6464 whom an inability to access their tools or their cloud-stored data can pose an existential threat.
6565
66 1.3 inert data (and data formats)
67 ---------------------------------
66 2.3&emsp;inert data (and data formats)
67 --------------------------------------
6868
6969 Cragg coins the term "inert data"<mmm-embed path="../references/super-powers" wrap="sidenote"></mmm-embed> for the data
7070 created and left behind by apps and applications in the computing model that is currently prevalent: Most data today
7171 is either intrinsically linked to one specific application, that controls and limits access to the actual information,
72 or, even worse, stored in the cloud where users have no direct access at all. In the latter case users depend solely on
72 or, even worse, stored in the cloud where users have no direct access at all. In the latter case, users depend solely on
7373 online tools that require a stable network connection and a modern browser and could be modified, removed, or otherwise
7474 negatively impacted at any moment.
7575
7676 Aside from being inaccessible to users, the resulting complex proprietary formats are also opaque and useless to other
7777 applications and the operating system, which often is a huge missed opportunity:
78 The .docx format for example, commonly used for storing mostly textual data enriched with images and on occasion videos,
78 The .docx format, for example, commonly used for storing mostly textual data enriched with images and on occasion videos,
7979 is in fact a type of archive that can contain many virtual files internally, such as the various media files contained
8080 within. However this is completely unknown to the user and operating system, and so users are unable to access the
8181 contents in this way. As a result, editing an image contained in a word document is far from a trivial task: first the
8282 document has to be opened in a word processing application, then the image has to be exported from it and saved in its
8383 own, temporary file. This file can then be edited and saved back to disk. Once updated, the image may be reimported
8484 into the .docx document. If the word-processing application supports this, the old image may be replaced directly,
85 otherwise the user may have to remove the old image, insert the new one and carefully ensure that the positioning in
85 otherwise, the user may have to remove the old image, insert the new one, and carefully ensure that the positioning in
8686 the document remains intact.
8787
88 1.4 disjointed filesystems
89 --------------------------
88 2.4&emsp;disjointed filesystems
89 -------------------------------
9090
9191 The filesystems and file models used on modern computing devices generally operate on the assumption that every
9292 individual file stands for itself. Grouping of files in folders is allowed as a convenience for users, but most
93 applications only ever concern themselves with a single file at a time, independent of the context the file is stored in
94 in the filesystem.
93 applications only ever concern themselves with a single file at a time, independent of the context the file is stored
94 in.
9595
9696 Data rarely really fits this concept of individual files very well, and even when it does, it is rarely exposed to
97 the user that way: The 'Contacts' app on a mobile phone for example does not store each contacts's information in a
97 the user that way: The 'Contacts' app on a mobile phone, for example, does not store each contact's information in a
9898 separate 'file' (as the word may suggest initially), but rather keeps all information in a single database file,
9999 which is hidden away from the user. Consequently, access to the information contained in the database is only enabled
100100 through the contacts application's graphical interface, and not through other applications that generically operate on
101101 files.
102102
103 Another example illustrates how a more powerful file (organisation) system could render such formats and applications
104 obsolete: Given the simple task of collecting and arranging a mixed collection of images, videos and texts in order to
103 Another example illustrates how a more powerful file (organization) system could render such formats and applications
104 obsolete: Given the simple task of collecting and arranging a mixed collection of images, videos, and texts to
105105 brainstorm, many might be tempted to open an application like *Microsoft Word* or *Adobe Photoshop* and create a new
106106 document there. Both *Photoshop* files and *Word* documents are capable of containing texts and images, but when such
107107 content is copied into them from external sources, such as other files on the same computer, or quotes and links from
112112
113113 To avoid facing this dilemma, a more sensible system could leave the task of positioning and aggregating content of
114114 different types to one software component, while multiple different software components could be responsible for editing
115 the individual pieces of content, so that the most appropriate one can be chosen for each element. While creating the
115 the individual pieces of content so that the most appropriate one can be chosen for each element. While creating the
116116 technological interface between these components is certainly a challenge, the resulting system would greatly benefit
117117 from the exponentially-growing capabilities resulting from the modular reuse of components across many contexts: A rich
118118 text editor component could be used for example not just in a mixed media collection as proposed above, but also for
122122
123123 To summarize, for various reasons, the metaphors and driving concepts of computing interfaces today prevent users from
124124 deeply understanding the software they use and the data they own, from customizing and improving their experience and
125 interactions, and from properly owning, contextualising and connecting their data.
125 interactions, and from properly owning, contextualizing and connecting their data.
126126
127 Interestingly, these deficits do not appear throughout the history of today's computing systems, but are based in rather
128 recent developments in the field. In fact the most influential systems in the past aspired to the polar opposites, as I
127 Interestingly, these deficits do not appear throughout the history of today's computing systems but are based in rather
128 recent developments in the field. In fact, the most influential systems in the past aspired to the polar opposites, as I
129129 will show in the next section.
130130
131131 <!--
1515 inkandswitch
1616 linux-exec
1717 wikipedia
18 market-share
1819 osx-files
1920 renaming
21 lock-in
0 @online{lock:in,
1 title = {The Cloud is the Ultimate Vendor Lock-in},
2 url = {https://www.digital-manifesto.org/the-cloud-is-the-ultimate-vendor-lock-in/},
3 author = {Zielemans, François},
4 year = {2017},
5 visited = {2019-11-18},
6 }
0 @online{market:share,
1 title = {Operating System Market Share - Desktop and Mobile},
2 year = {2019},
3 url = {https://s-ol.nu/ba/ref/nms},
4 oldURL = {https://netmarketshare.com/operating-system-market-share.aspx?options=%7B%22filter%22%3A%7B%22%24and%22%3A%5B%7B%22deviceType%22%3A%7B%22%24in%22%3A%5B%22Desktop%2Flaptop%22%2C%22Mobile%22%5D%7D%7D%5D%7D%2C%22dateLabel%22%3A%22Trend%22%2C%22attributes%22%3A%22share%22%2C%22group%22%3A%22platform%22%2C%22sort%22%3A%7B%22share%22%3A-1%7D%2C%22id%22%3A%22platformsDesktop%22%2C%22dateInterval%22%3A%22Monthly%22%2C%22dateStart%22%3A%222018-12%22%2C%22dateEnd%22%3A%222019-11%22%2C%22hiddenSeries%22%3A%7B%7D%2C%22tableOrder%22%3A%5B%5B2%2C%22desc%22%5D%5D%2C%22segments%22%3A%22-1000%22%7D},
5 publisher = {NetMarketShare},
6 }
44 refs = for ref in *@children
55 li ref\gett 'mmm/dom'
66 div {
7 class: 'print-ownpage'
8
79 h1 "references", id: 'references'
810 ol with refs
911 refs.style = 'line-height': 'normal'
1111 let num = 0;
1212 for (e of list) {
1313 while (e.num > num) {
14 str += '<ol style="list-style: none;">'
14 str += '<ol style="list-style: none; padding-left: 2rem;">'
1515 num += 1;
1616 }
1717
3333 <ol style="list-style: none;">
3434 <li><a href="#abstract">abstract</a></li>
3535 <li><a href="#table-of-contents">table of contents</a></li>
36 <li><a href="#overview">overview</a></li>
37 <li><a href="#1-motivation">1. motivation</a></li>
38 <ol style="list-style: none;">
39 <li><a href="#11-application-centric-design">1.1 application-centric design</a></li>
40 <li><a href="#12-cloud-computing">1.2 cloud computing</a></li>
41 <li><a href="#13-inert-data-and-data-formats">1.3 inert data (and data formats)</a></li>
42 <li><a href="#14-disjointed-filesystems">1.4 disjointed filesystems</a></li>
36 <li><a href="#1introduction">1&emsp;introduction</a></li>
37 <li><a href="#2drawbacks-of-current-systems">2&emsp;drawbacks of current systems</a></li>
38 <ol style="list-style: none; padding-left: 2rem;">
39 <li><a href="#21application-centric-design">2.1&emsp;application-centric design</a></li>
40 <li><a href="#22cloud-computing">2.2&emsp;cloud computing</a></li>
41 <li><a href="#23inert-data-and-data-formats">2.3&emsp;inert data (and data formats)</a></li>
42 <li><a href="#24disjointed-filesystems">2.4&emsp;disjointed filesystems</a></li>
4343 </ol>
44 <li><a href="#2-historical-approaches">2. historical approaches</a></li>
45 <li><a href="#3-evaluation-framework">3. evaluation framework</a></li>
46 <ol style="list-style: none;">
47 <li><a href="#31-qualities-of-successful-end-user-computing">3.1 qualities of successful end-user computing</a></li>
48 <li><a href="#32-modularity">3.2 modularity</a></li>
49 <li><a href="#33-content-transclusion">3.3 content transclusion</a></li>
50 <li><a href="#34-end-user-programming">3.4 end-user programming</a></li>
44 <li><a href="#3historical-approaches">3&emsp;historical approaches</a></li>
45 <li><a href="#4evaluation-framework">4&emsp;evaluation framework</a></li>
46 <ol style="list-style: none; padding-left: 2rem;">
47 <li><a href="#41qualities-of-successful-end-user-computing">4.1&emsp;qualities of successful end-user computing</a></li>
48 <li><a href="#42modularity">4.2&emsp;modularity</a></li>
49 <li><a href="#43content-transclusion">4.3&emsp;content transclusion</a></li>
50 <li><a href="#44end-user-programming">4.4&emsp;end-user programming</a></li>
5151 </ol>
52 <li><a href="#4-system-description">4. system description</a></li>
53 <ol style="list-style: none;">
54 <li><a href="#41-data-storage-model">4.1 data storage model</a></li>
55 <li><a href="#42-type-system-and-coercion-engine">4.2 type system and coercion engine</a></li>
52 <li><a href="#5system-description">5&emsp;system description</a></li>
53 <ol style="list-style: none; padding-left: 2rem;">
54 <li><a href="#51data-storage-model">5.1&emsp;data storage model</a></li>
55 <li><a href="#52type-system-and-coercion-engine">5.2&emsp;type system and coercion engine</a></li>
5656 </ol>
57 <li><a href="#5-example-use-cases">5. example use-cases</a></li>
58 <ol style="list-style: none;">
59 <li><a href="#51-publishing-and-blogging">5.1 publishing and blogging</a></li>
60 <ol style="list-style: none;">
61 <li><a href="#511-blogging">5.1.1 blogging</a></li>
62 <li><a href="#512-scientific-publishing">5.1.2 scientific publishing</a></li>
57 <li><a href="#6example-use-cases">6&emsp;example use-cases</a></li>
58 <ol style="list-style: none; padding-left: 2rem;">
59 <li><a href="#61publishing-and-blogging">6.1&emsp;publishing and blogging</a></li>
60 <ol style="list-style: none; padding-left: 2rem;">
61 <li><a href="#611blogging">6.1.1&emsp;blogging</a></li>
62 <li><a href="#612scientific-publishing">6.1.2&emsp;scientific publishing</a></li>
6363 </ol>
64 <li><a href="#52-pinwall">5.2 pinwall</a></li>
65 <li><a href="#53-slideshow">5.3 slideshow</a></li>
64 <li><a href="#62pinwall">6.2&emsp;pinwall</a></li>
65 <li><a href="#63slideshow">6.3&emsp;slideshow</a></li>
6666 </ol>
67 <li><a href="#6-evaluation">6. evaluation</a></li>
68 <ol style="list-style: none;">
69 <li><a href="#61-examples">6.1 examples</a></li>
70 <ol style="list-style: none;">
71 <li><a href="#611-publishing-and-blogging">6.1.1 publishing and blogging</a></li>
72 <li><a href="#612-pinwall">6.1.2 pinwall</a></li>
73 <li><a href="#613-slideshow">6.1.3 slideshow</a></li>
67 <li><a href="#7evaluation">7&emsp;evaluation</a></li>
68 <ol style="list-style: none; padding-left: 2rem;">
69 <li><a href="#71examples">7.1&emsp;examples</a></li>
70 <ol style="list-style: none; padding-left: 2rem;">
71 <li><a href="#711publishing-and-blogging">7.1.1&emsp;publishing and blogging</a></li>
72 <li><a href="#712pinwall">7.1.2&emsp;pinwall</a></li>
73 <li><a href="#713slideshow">7.1.3&emsp;slideshow</a></li>
7474 </ol>
75 <li><a href="#62-general-concerns">6.2 general concerns</a></li>
76 <ol style="list-style: none;">
77 <li><a href="#621-global-set-of-converts">6.2.1 global set of converts</a></li>
78 <li><a href="#622-code-outside-of-the-system">6.2.2 code outside of the system</a></li>
79 <li><a href="#623-type-system">6.2.3 type system</a></li>
80 <li><a href="#624-type-coercion">6.2.4 type-coercion</a></li>
81 <li><a href="#625-in-system-editing">6.2.5 in-system editing</a></li>
75 <li><a href="#72general-concerns">7.2&emsp;general concerns</a></li>
76 <ol style="list-style: none; padding-left: 2rem;">
77 <li><a href="#721global-set-of-converts">7.2.1&emsp;global set of converts</a></li>
78 <li><a href="#722code-outside-of-the-system">7.2.2&emsp;code outside of the system</a></li>
79 <li><a href="#723type-system">7.2.3&emsp;type system</a></li>
80 <li><a href="#724type-coercion">7.2.4&emsp;type-coercion</a></li>
81 <li><a href="#725in-system-editing">7.2.5&emsp;in-system editing</a></li>
82 <li><a href="#726end-user-adoption">7.2.6&emsp;end-user adoption</a></li>
8283 </ol>
8384 </ol>
84 <li><a href="#7-conclusion">7. conclusion</a></li>
85 <li><a href="#8conclusion">8&emsp;conclusion</a></li>
8586 <li><a href="#references">references</a></li>
8687 <li><a href="#ba-log">appendix: project log</a></li>
8788 <li><a href="#statement">statement of originality</a></li>
00 <div class="print-only print-ownpage" style="font-size: 1.5rem; width: calc(100% + var(--sidenote-width))">
11 <div style="font-size: 2rem; margin-top: 4cm">
2 <h1>Empowered End-User Computing</h1>
2 <h1>Empowered End-User Computing:</h1>
33 <span>A Historical Investigation and Development of a File-System-Based Environment</span>
44 </div>
55 <div style="width: 14cm; margin: 4cm auto 0">