From 3c03612dda10b3dcc38c9bc2c96d8a539518f2db Mon Sep 17 00:00:00 2001 From: s-ol Date: Wed, 1 Jan 2020 19:41:01 +0100 Subject: introduction --- root/articles/mmmfs/$order | 1 + .../mmmfs/abstract/text$markdown+sidenotes.md | 12 ++- .../print: text$moonscript -> fn -> mmm$dom.moon | 2 +- .../ba_log/text$moonscript -> fn -> mmm$dom.moon | 2 +- .../mmmfs/conclusion/text$markdown+sidenotes.md | 21 +++--- .../mmmfs/evaluation/text$markdown+sidenotes.md | 64 +++++++++------- .../implementation: text$markdown+sidenotes.md | 36 ++++----- .../examples/intro: text$markdown+sidenotes.md | 4 +- .../examples/text$moonscript -> fn -> mmm$dom.moon | 9 ++- .../mmmfs/framework/text$markdown+sidenotes.md | 38 +++++----- .../text$markdown+sidenotes.md | 28 +++---- root/articles/mmmfs/introduction/text$markdown.md | 18 +++++ .../mmmfs/mmmfs/text$markdown+sidenotes.md | 59 ++++++++------- .../mmmfs/motivation/text$markdown+sidenotes.md | 70 +++++++++--------- root/articles/mmmfs/references/$order | 2 + root/articles/mmmfs/references/lock-in/text$bibtex | 7 ++ .../mmmfs/references/market-share/text$bibtex | 7 ++ .../text$moonscript -> fn -> mmm$dom.moon | 2 + .../mmmfs/table-of-contents/text$html+frag.html | 85 +++++++++++----------- root/articles/mmmfs/title/text$html+frag.html | 2 +- 20 files changed, 271 insertions(+), 198 deletions(-) create mode 100644 root/articles/mmmfs/introduction/text$markdown.md create mode 100644 root/articles/mmmfs/references/lock-in/text$bibtex create mode 100644 root/articles/mmmfs/references/market-share/text$bibtex (limited to 'root') diff --git a/root/articles/mmmfs/$order b/root/articles/mmmfs/$order index 563d544..d58d878 100644 --- a/root/articles/mmmfs/$order +++ b/root/articles/mmmfs/$order @@ -1,6 +1,7 @@ title abstract table-of-contents +introduction motivation historical-approaches framework diff --git a/root/articles/mmmfs/abstract/text$markdown+sidenotes.md b/root/articles/mmmfs/abstract/text$markdown+sidenotes.md index 975fecc..c7d6c9c 100644 --- a/root/articles/mmmfs/abstract/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/abstract/text$markdown+sidenotes.md @@ -1,4 +1,14 @@ abstract ======== -
[section under construction]
+Current end-user operating systems are based on a set of design principles and computing paradigms that make them +simple to use in some circumstances but are very inflexible for user customization and adaptation. In this thesis, these +limitations and design principles will be discussed and contrasted by an analysis of historic systems that solved these +issues by following different design goals. Based on this analysis, as well as further literature, an evaluation +framework for end-user computing systems is established. +The design and implementation of a new end-user computing system, which focuses on a file system with rich file types +and a type coercion system as its central paradigm, is discussed. Following this, the capabilities of the system are +demonstrated using multiple example use-cases. An evaluation of these examples as well as the system itself according +to the framework established earlier shows that the proposed system is indeed very flexible and useful for a wide +variety of uses involving multimedia content from various sources, although the system has many flaws that would hinder +widespread adoption. diff --git a/root/articles/mmmfs/ba_log/print: text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/ba_log/print: text$moonscript -> fn -> mmm$dom.moon index 97a6283..97ebd4c 100644 --- a/root/articles/mmmfs/ba_log/print: text$moonscript -> fn -> mmm$dom.moon +++ b/root/articles/mmmfs/ba_log/print: text$moonscript -> fn -> mmm$dom.moon @@ -6,7 +6,7 @@ import ropairs from require 'mmm.ordered' div { class: 'print-ownpage' - h1 (link_to @, "appendix: project log"), id: 'ba-log' + h1 (link_to @, "appendix: project log"), id: 'ba-log' @gett 'intro: mmm/dom' table.unpack for post in *@children continue if post\get 'hidden: bool' diff --git a/root/articles/mmmfs/ba_log/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/ba_log/text$moonscript -> fn -> mmm$dom.moon index bd2859d..b6b0756 100644 --- a/root/articles/mmmfs/ba_log/text$moonscript -> fn -> mmm$dom.moon +++ b/root/articles/mmmfs/ba_log/text$moonscript -> fn -> mmm$dom.moon @@ -4,7 +4,7 @@ import ropairs from require 'mmm.ordered' => div { - h1 (link_to @, "appendix: project log"), id: 'ba-log' + h1 (link_to @, "appendix: project log"), id: 'ba-log' @gett 'intro: mmm/dom' ul do posts = for post in *@children diff --git a/root/articles/mmmfs/conclusion/text$markdown+sidenotes.md b/root/articles/mmmfs/conclusion/text$markdown+sidenotes.md index 55052be..92230a0 100644 --- a/root/articles/mmmfs/conclusion/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/conclusion/text$markdown+sidenotes.md @@ -1,14 +1,11 @@ -# 7. conclusion +# 8 conclusion -
[section under construction]
+The historical analysis and the evaluation of the proposed system show that many of the limitations of current +mainstream operating systems can be worked around effectively. The flaws can also be attributed in part to some +concrete design paradigms, which future system designers may seek to avoid. To this end, the framework provided for +evaluation may also be useful. -In the beginning of this thesis multiple downsides of the most widely used end-user computing systems have been -demonstrated and attributed to an over-reliance on a set of design paradigms that do not align well with the goal of -empowering users. On the other hand, it has been shown that many well-recognized historic systems were designed with -this goal in mind. - -Based on the aspirations and appraoches of these historic systems, a framework for the evaluation of empowering end-user -computing systems was developed alongside one such system itself. While the proposed system has been shown to have many -flaws and limitations of its own, and is not currently viable as a tool for end-users, it serves to demonstrate the -feasiblity of type coercion and the file system as a focus point for new end-user computing systems, and provides a -reference point for further research. +The system proposed and developed in the project corresponding to this thesis has been shown to successfully implement +many of the properties were hoped to be achieved, such as a modular and consistent architecture and strong support for +mixed-content transclusions. On the other hand, some limitations in the design are apparent. Many of these limitations +constitute candidate topics for further research, and most can be attributed to trade-offs made in the development process. diff --git a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md index 2eb3acf..65024d4 100644 --- a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md @@ -1,12 +1,12 @@ -# 6. evaluation -In this section I will first take a look at the implementations of the examples for the use cases outlined above, +# 7 evaluation +In this section, I will first take a look at the implementations of the examples for the use cases outlined above, and evaluate them with regard to the framework derived in the corresponding section above. After that, some general concerns and insights that have become apparent while developing the system and working with it will be reviewed. -## 6.1 examples -### 6.1.1 publishing and blogging -Since mmmfs has grown out of the need for a versatile content-management system for a personal website and blog, it is -not surprising to see that it is still up to that job. Nevertheless it is worth taking a look at its strengths and +## 7.1 examples +### 7.1.1 publishing and blogging +Since mmmfs has grown out of the need for a versatile content management system for a personal website and blog, it is +not surprising to see that it is still up to that job. Nevertheless, it is worth taking a look at its strengths and weaknesses in this context: The system has proven itself perfect for publishing small- and medium-size articles and blog posts, especially for its @@ -20,12 +20,12 @@ table-of-contents and section numbering were less obvious to tackle and finally This is mostly due to the approach of splitting up the thesis into a multitude of fileders, and the current lack of mechanisms to re-capture information spread throughout the resulting hierarchy effectively. -### 6.1.2 pinwall +### 7.1.2 pinwall The pinwall example shows some strengths of the mmmfs system pretty convincingly. The type coercion layer completely abstracts away the complexities of transcluding different types of content, and only positioning and sizing the content, as well as enabling interaction, remain to handle in the pinwall fileder. -A great benefit of the use of mmmfs versus other technology for realising this example is that the example can +A great benefit of the use of mmmfs versus other technology for realizing this example is that the example can seamlessly embed not only plain text, markdown, images, videos, and interactive widgets, but also follow links to all of these types of content, and display them meaningfully. Accomplishing this with traditional frameworks would take great effort, where mmmfs benefits from the reuse of these conversions across the whole system. @@ -35,7 +35,7 @@ take care of capturing and handling JS events. The bulk of complexity is therefo UI layer (in this case the browser), which could feasibly be simplified through a custom abstraction layer or the use of output means other than the web. -### 6.1.3 slideshow +### 7.1.3 slideshow A simplified image slideshow example consists of only 20 lines of code and demonstrates how the reactive component framework simplifies the generation of ad-hoc UI dramatically: @@ -66,17 +66,17 @@ such as the fullscreen API and sizing content proportionally to the viewport siz The parts of the code dealing with the content are essentially identical, except that content is transcluded via the more general `mmm/dom` type-interface, allowing for a greater variety of types of content to be used as slides. -## 6.2 general concerns +## 7.2 general concerns While the system has proven pretty successful and moldable to the different use-cases that it has been tested in, there are also limitations in the proposed system that have become obvious in developing and working with the system. -In this section these limitations will be discussed individually, and directions for further research and solutions will +In this section, these limitations will be discussed individually, and directions for further research and solutions will be given where apparent. -### 6.2.1 global set of converts +### 7.2.1 global set of converts In the current system, there is only a single, global set of *converts* that can be potentially applied to facets anywhere in the system. -Therefore it is necessary to encode behaviour directly (as code) in facets wherever exceptional behaviour is required. -For example if a fileder containing multiple images wants to provide custom UI for each image when viewed independently, +Therefore it is necessary to encode behavior directly (as code) in facets wherever exceptional behavior is required. +For example, if a fileder containing multiple images wants to provide custom UI for each image when viewed independently, this code has to either be attached to every image individually (and redundantly), or added as a global convert. To make sure this convert does not interfere with images elsewhere in the system, it would be necessary to introduce a new type and change the images to use it, which may present even more problems, and works against the principle of @@ -86,15 +86,15 @@ A potential direction of research in the future is to allow specifying *converts Application of *converts* could then be scoped to their fileders' subtrees, such that for any facet only the *converts* stored in the chain of its parents upwards are considered. This way, *converts* can be added locally if they only make sense within a given context. -Additionally it could be made possible to use this mechanism to locally override *converts* inherited from -further up in the tree, for example to specialize types based on their context in the system. +Additionally, it could be made possible to use this mechanism to locally override *converts* inherited from +further up in the tree, for example, to specialize types based on their context in the system. See also The biggest downside to this approach would be that it presents another pressure factor for, while also reinforcing, the hierarchical organization of data, thereby exacerbating the limits of hierarchical structures. -### 6.2.2 code outside of the system -At the moment, a large part of the mmmfs codebase is still separate from the content, and developed outside of mmmfs +### 7.2.2 code outside of the system +At the moment, a large part of the mmmfs codebase is still separate from the content and developed outside of mmmfs itself. This is a result of the development process of mmmfs and was necessary to start the project as the filesystem itself matured, but has now become a limitation of the user experience: potential users of mmmfs would generally start by becoming familiar with the operation of mmmfs from within the system, as this is the expected (and designated) @@ -104,25 +104,27 @@ to them, actively limiting their understanding, and thereby the customizability, This weakness represents a failure to (fully) implement the quality of a "Living System" as proposed by *Ink and Switch*. -In general however, some portion of code may always have to be left outside of the system. +In general, however, some portion of code may always have to be left outside of the system. This also wouldn't necessarily represent a problem, but in this case it is particularly relevant for the global set of *converts* (see above), as well as the layout used to render the web view. Both of these are expected to undergo changes as users adapt the system to their own content types and domains of interest, as well as their visual identity, respectively. -### 6.2.3 type system -The currently used type system based on strings and pattern matching has been largely satisfactory, +### 7.2.3 type system +The currently used type system based on strings and pattern matching has been largely satisfactory but has proven problematic for some anticipated use cases. It should be considered to switch to a more intricate, structural type system that allows encoding more concrete meta-data alongside the type, and to match *converts* based on a more flexible scheme of pattern matching. -For example it is envisaged to store the resolution of an image file in its type. +For example, it is envisaged to store the resolution of an image file in its type. Many *converts* might choose to ignore this additional information, but others could use this information to generate lower-resolution 'thumbnails' of images automatically. Using these mechanisms for example images could be requested with a maximum-resolution constraint to save on bandwidth when embedded in other documents. -### 6.2.4 type-coercion +
+ +### 7.2.4 type-coercion By giving the system more information about the data it is dealing with, and then relying on the system to automatically transform between data-types, it is easy to lose track of which format data is concretely stored in. @@ -134,10 +136,10 @@ This poses a threat to the transparency of the system, and potentially a lack of Potential solutions could be to communicate the conversion path clearly and explicitly together with the content, as well as making this display interactive to encourage experimentation with custom conversion queries. -Emphasising the conversion process more strongly in this way might be a way to turn this feature from an opaque +Emphasizing the conversion process more strongly in this way might be a way to turn this feature from an opaque hindrance into a transparent tool. This should represent a challenge mostly in terms of UX and UI design. -### 6.2.5 in-system editing +### 7.2.5 in-system editing Because many *converts* are not necessarily reversible, it is very hard to implement generic ways of editing stored data in the same format it is viewed. For example, the system trivially converts markdown-formatted text sources into viewable HTML markup, but it is hardly possible to propagate changes to the viewable HTML back to the markdown source. @@ -156,6 +158,16 @@ fragmentation of content that mmmfs encourages. As a result, interacting with the system at large is still a very different experience from editing content (and thereby extending the system) in it. This is expected to represent a major hurdle for users getting started with the -system, and is a major shortcoming in enabling end-user programming, as set as a goal for this project. +system and is a major shortcoming in enabling end-user programming, as set as a goal for this project. A future iteration should carefully reconsider how editing could be integrated more holistically with the other core concepts of the design. + +
+ +### 7.2.6 end-user adoption +As mentioned above, a conscious choice was made to exclude the implementation of a dedicated end-user programming +facility in the system, and instead conventional programming languages and mechanisms were relied upon as the central +way of customizing the system and experience. While this was a crucial choice to make in order to proceed with the +project as a whole, it means that the system currently can not be adopted and used to its full extent by +end-users. This also means that a full evaluation of the system with regard to end-user empowerment has to be left open +until this can be changed by further work. diff --git a/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md b/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md index 0a82a51..8a6a185 100644 --- a/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md +++ b/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md @@ -1,20 +1,20 @@ -## 5.1 publishing and blogging -### 5.1.1 blogging -Blogging is pretty straightforward, since it generally just involves publishing lightly-formatted text, +## 6.1 publishing and blogging +### 6.1.1 blogging +Blogging is pretty straightforward since it generally just involves publishing lightly-formatted text, interspersed with media such as images and videos or perhaps social media posts. -Markdown is a great tool for this job, and has been integrated in the system to much success: +Markdown is a great tool for this job, and has been integrated into the system to much success: There are two different types registered with *converts*: `text/markdown` and `text/markdown+span`. They both render to HTML (and DOM nodes), so they are immediately viewable as part of the system. The only difference for `text/markdown+span` is that it is limited to a single line, and doesn't render as a paragraph but rather just a line of text. This makes it suitable for denoting formatted-text titles and other small strings of text. -The problem of embedding other content together with text comfortably is also solved easily, +The problem of embedding other content together with text comfortably is also solved easily because Markdown allows embedding arbitrary HTML in the document. This made it possible to define a set of pseudo-HTML elements in the Markdown-convert, `` and ``, which respectively embed and link to other content native to mmmfs. -### 5.1.2 academic publishing +### 6.1.2 academic publishing
One of the 'standard' solutions, LaTeX, is arguably at least as complex as the mmm system proposed here, but has a much narrower scope, @@ -22,13 +22,13 @@ since it does not support interaction.
Academic publishing is notoriously complex, involving not only the transclusion of diagrams -and other media, but generally requiring precise and consistent control over formatting and layout. -Some of these complexities are tedious to manage, but present good opportunities for programmatic +and other media but generally requiring precise and consistent control over formatting and layout. +Some of these complexities are tedious to manage but present good opportunities for programmatic systems and media to do work for the writer. One such topic is the topic of references. -References appear in various formats at multiple positions in a academic document; -usually they are referenced via a reduced visual form within the text of the document, +References appear in various formats at multiple positions in an academic document; +usually, they are referenced via a reduced visual form within the text of the document and then shown again with full details at the end of the document. For the sake of this thesis, referencing has been implemented using a subset of the popular @@ -42,18 +42,18 @@ API for accessing BibTeX citations for documents in the library. This means that ACM DL entry in mmmfs, and the reference will automatically be fetched, and therefore stay up to date with potential remote corrections. -## 5.2 pinwall -In many situations, in particular for creative work, it is often useful to compile resources of -different types for reference or inspiration, and arrange them spatially so that they can be viewed -at a glance or organized into different contexts etc. +## 6.2 pinwall +In many situations, and particularly for creative work, it is often useful to compile resources of +different types for reference or inspiration and arrange them spatially so that they can be viewed +at a glance or organized into different contexts, etc. Such a pinwall could serve for example to organize references to articles, -to collect visual inspiration for a moodboard etc. +to collect visual inspiration for a mood board, etc. As a collection, the Pinwall is primarily mapped to a Fileder in the system. Any content that is placed within can then be rendered by the Pinwall, which can constrain every piece of content to a rectangular piece on its canvas. This is possible through a simple script, e.g. of the type `text/moonscript -> fn -> mmm/dom`, -which enumerates the list of children, wraps each in such a rectangular container, +which enumerates the list of children, wraps each in such a rectangular container and outputs the list of containers as DOM elements. The position and size of each panel are stored in an ad-hoc facet, encoded in the JSON data format: @@ -66,7 +66,7 @@ on the upper border or lower right-hand corner respectively. Whenever a change is made the event handler can then update the value in the `pinwall_info` facet, so that the updated position and size are stored for the next time the pinwall is opened. -## 5.3 slideshow +## 6.3 slideshow Another common use of digital documents is as aids in a verbal presentation. These often take the form of slideshows, for the creation of which a number of established applications exist. In simple terms, a slideshow is simply a linear series of screen-sized documents, that can be @@ -79,7 +79,7 @@ It also allows putting the browser into fullscreen mode to maximize screen space of the website that may distract from the presentation, and register an event handler for keyboard accelerators for moving through the presentation. -Finally the script simply embeds the first of its child-fileders into the viewport rectangle. +Finally, the script simply embeds the first of its child-fileders into the viewport rectangle. Once the current slide is changed, the next embedded child is simply chosen.