One of the 'standard' solutions, LaTeX, is arguably at least as complex as the mmm system proposed here, but has a much narrower scope, since it does not support interaction.

+ Scientific 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 @@ -43,9 +44,9 @@ type to convert to a full reference format (to `mmm/dom`) and to an inline side- For convenience, a convert from the `URL -> cite/acm` type has been provided to `URL -> text/bibtex`, which generates links to the ACM Digital Library -API for accessing BibTeX citations for documents in the library. -This means that it is enough to store the link to the ACM DL entry in mmmfs, -and the reference will automatically be fetched (and track potential remote corrections). +API for accessing BibTeX citations for documents in the library. This means that it is enough to store the link to the +ACM DL entry in mmmfs, and the reference will automatically be fetched, and therefore stay up to date with potential +remote corrections. ## pinwall In many situations, in particular for creative work, it is often useful to compile resources of @@ -62,14 +63,14 @@ which enumerates the list of children, wraps each in such a rectangular containe 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: -`pinwall_info: text/json`. This facet can then set on each child and accessed whenever the script is called +`pinwall_info: text/json`. Such a facet is set on each child and read whenever the script is called to render the children, plugging the values within the facet into the visual styling of the document. The script can also set event handlers that react to user input while the document is loaded, and allow the user to reposition and resize the individual pinwall items by clicking and dragging 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 script places the content at the updated position and size next time it is invoked. +so that the updated position and size are stored for the next time the pinwall is opened. ## slideshow Another common use of digital documents is as aids in a verbal presentation. @@ -84,8 +85,10 @@ It also allows putting the browser into fullscreen mode to maximise screenspace 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 rect. -One the current slide is changed, the next embedded child is simply chosen. +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. + diff --git a/root/articles/mmmfs/examples/markdown/preview: text$markdown.md b/root/articles/mmmfs/examples/markdown/preview: text$markdown.md deleted file mode 100644 index 4b38ef2..0000000 --- a/root/articles/mmmfs/examples/markdown/preview: text$markdown.md +++ /dev/null @@ -1,6 +0,0 @@ -See I have like - -- a list of things -- (two things) - -and some bold **text** and `code tags` with me. diff --git a/root/articles/mmmfs/examples/markdown/text$markdown.md b/root/articles/mmmfs/examples/markdown/text$markdown.md new file mode 100644 index 0000000..880eedb --- /dev/null +++ b/root/articles/mmmfs/examples/markdown/text$markdown.md @@ -0,0 +1,20 @@ +This is a markdown document rendered using [marked][marked] on the client, and [discount][discount] on the server. +All Markdown features are supported, for example there is support for lists... + +- a list of things +- (two things) + +...and syntax-highlighted code tags: + +``` +print "Hello World" +``` + +Since Markdown supports inline HTML, mmmfs shorthands can also be used to embed and reference content from elsewhere in +the system. For example, the title of this fileder can be embedded using +``: + + + +[marked]: https://marked.js.org/ +[discount]: https://luarocks.org/modules/craigb/discount diff --git a/root/articles/mmmfs/examples/markdown/title: text$plain b/root/articles/mmmfs/examples/markdown/title: text$plain index 319068d..7915148 100644 --- a/root/articles/mmmfs/examples/markdown/title: text$plain +++ b/root/articles/mmmfs/examples/markdown/title: text$plain @@ -1 +1 @@ - I'm not even five lines of markdown but i render myself! +markdown content diff --git a/root/articles/mmmfs/examples/pinwall/title: text$plain b/root/articles/mmmfs/examples/pinwall/title: text$plain index 9d29c5d..c629992 100644 --- a/root/articles/mmmfs/examples/pinwall/title: text$plain +++ b/root/articles/mmmfs/examples/pinwall/title: text$plain @@ -1 +1 @@ -A pinwall +a pinwall diff --git a/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon index c79ffcf..1401e95 100644 --- a/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon +++ b/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon @@ -13,7 +13,7 @@ title = child\gett 'title', 'text/plain' -- get 'preview' as a DOM description (nil if no value or conversion possible) - content = child\get 'preview', 'mmm/dom' + -- content = child\get 'preview', 'mmm/dom' -- div { -- h4 title, style: { margin: 0, cursor: 'pointer' }, onclick: -> BROWSER\navigate child.path @@ -31,10 +31,15 @@ li link_to child - content = ul for child in *@children - preview child + examples = div { + style: + position: 'relative' + 'margin-top': '4rem' - -- table.insert content, 1, (@gett 'intro: mmm/dom') - -- div content + div "The online version is available at ", (a "s-ol.nu/ba", href: 'https://s-ol.nu/ba'), ".", class: 'sidenote' + "The following examples can be viewed and inspected in the interactive version online:" + ul for child in *@children + preview child + } - div (@gett 'intro: mmm/dom'), content + div (@gett 'intro: mmm/dom'), examples diff --git a/root/articles/mmmfs/framework/text$markdown+sidenotes.md b/root/articles/mmmfs/framework/text$markdown+sidenotes.md index 48e6a2c..f62c581 100644 --- a/root/articles/mmmfs/framework/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/framework/text$markdown+sidenotes.md @@ -22,16 +22,16 @@ end-user programming describes the software design paradigm pioneered in the creation of the Unix operating system at the AT&T Bell Labs research center in the 1960s. The -concepts are considered quite influental and are still notably applied in the Linux community. Many attempts at +concepts are considered quite influential and are still notably applied in the Linux community. Many attempts at summaries exist, but the following includes the pieces that are especially relevant even today: > Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes @@ -47,13 +47,13 @@ in such a way that it is easy to integrate for the user later. Assembling the sy interacting pieces also enables future growth and customization, since pieces may be swapped out with customized or alternate software at any time. -Settling on a specific modular design model, and reifying other components of a system in terms of it also corresponds +Settling on a specific modular design model, and reifying other components of a system in terms of it, also corresponds directly to the concept of *Embodiment* described by Ink & Switch. content transclusion -------------------- -The strengths of modular architectures should similarily also extend into the way the system will be used by users. +The strengths of modular architectures should similarily extend also into the way the system will be used by users. If users are to store their information and customized behaviour in such an architecture, then powerful tools need to be present in order to assemble more complex solutions out of such parts. Therefore static content should be able to be linked to (as envisioned for the *Memex*, see above), but also to be , the concept predates much of the technology that later was used to implement many parts of the vision. + One of the most innovative elements of Bush's predictions is the idea of technologically cross-referenced and connected information, which would later be known and created as *hypertext*. While hypertext powers the majority of today's internet, many of the advantages that Bush imagined have not carried over into the personal use of computers. -There are very few tools for creating personal, highly-interconnected knowledgebases, even though this is technically -feasible, and a proven concept (exemplified for example by the massively successful online encyclopedia +There are very few tools for creating personal, highly-interconnected knowledgebases, even though it is technologically +feasible and a proven concept (exemplified for example by the massively successful online encyclopedia *Wikipedia*). While there are little such tools available today, one of the systems that could be said to have come closest to a -practical implementation of such a Memex-inspired system for personal use might be Apple's *HyperCard*. +practical implementation of a Memex-inspired system for personal use might be Apple's *HyperCard*. In a live demonstration, the creators of the software showcase a system of stacks of cards that together implement, amongst others, a calendar (with yearly and @@ -62,8 +64,8 @@ automatically looking up the card corresponding to a person's first name from a different card. Alongside Spreadsheets, *HyperCard* remains one of the most successful implementations of end-user programming, even -today. While it's technical abilities have been long matched and surpassed by other software (such as the ubiquitous -*Hypertext Markup Language*, HTML), these technical successors have failed the legacy of *HyperCard* as an end-user -tool: while it is easier than ever to publish content on the web (through various social media and microblogging -services), the benefits of hypermedia as a customizable medium for personal management have nearly vanished. -End-users do not create hypertext anymore. +today. While its technical abilities have been long matched and surpassed by other software (such as the ubiquitous +*Hypertext Markup Language*, HTML and the associated programming language *JavaScript*), these technical successors have +failed the legacy of *HyperCard* as an end-user tool: While it is easier than ever to publish content on the web +(through various social media and microblogging services), the benefits of hypermedia as a customizable medium for +personal management have nearly vanished. End-users do not create hypertext anymore. diff --git a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md index bf1ed9b..c2bbee5 100644 --- a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md @@ -20,17 +20,18 @@ Like many data storage models it is based fundamentally on the concept of a hier schematic view of an example tree in a mainstream filesystem In common filesystems, as pictured, data can be organized hierarchically into *folders* (or *directories*), -which serve only as containers of *files*, in which data is actually stored. -While *directories* are fully transparent to both system and user (they can be created, browser, listed and viewed by both), -*files* are, from the system perspective, mostly opaque and inert blocks of data. +which serve only as containers of *files*, in which data is actually stored. While *directories* are fully transparent +to both system and user (they can be created, browsed, listed and viewed by both), *files* are, from the system +perspective, mostly opaque and inert blocks of data. Some metadata, such as file size and access permissions, is associated with each file, but notably the type of data is generally not actually stored in the filesystem, but determined loosely based on multiple heuristics depending on the system and context. Some notable mechanism are: -- Suffixes in the name are often used to indicate what kind of data a file should contain. However there is no standardization -- over this, and often a suffix is used for multiple incompatible versions of a file-format. +- Suffixes at the end of the filename are often used to indicate which kind of data a file contains. However there is no + centralized standardization of suffixes, and often one suffix is used for multiple incompatible versions of a + file-formats, or multiple suffixes are used interchangeably for one format. - Many file-formats specify a specific data-pattern either at the very beginning or very end of a given file. On unix systems the `libmagic` database and library of these so-called *magic constants* is commonly used to guess the file-type based on these fragments of data. @@ -41,44 +42,50 @@ Some notable mechanism are: It should be clear already from this short list that to mainstream operating systems, as well as the applications running on them, the format of a file is almost completely unknown and at best educated guesses can be made. -Because these various mechanisms are applied at different times by the operating system and applications, -it is possible for files to be labelled as or considered as being in different formats at the same time by different -components of the system. - + +Because these various mechanisms are applied at different times by the operating system and applications, it is possible +for files to be labelled or considered as being in different formats at the same time by different components of the +system. + This leads to confusion about the factual format of data among users, but can also pose a serious security risk: Under some circumstances it is possible that a file contains maliciously-crafted code and is treated as an executable by one software component, while a security mechanism meant to detect such code determines the same file to be a legitimate image (the file may in fact be valid in both formats). -In mmmfs, the example above might look like this instead: +In mmmfs, the example above might look like this instead: schematic view of an example mmmfs tree -Superficially, this may look quite similar: there is still only two types of nodes (referred to as *fileders* and *facets*), -and again one of them, the *fileders* are used only to hierarchically organize *facets*. -Unlike *files*, *factes* don't only store a freeform *name*, there is also a dedicated *type* field associated with every *facet*, -that is explicitly designed to be understood and used by the system. +Superficially, this may look quite similar: there is still only two types of nodes (referred to as *fileders* and +*facets*), and again one of them, the *fileders* are used only to hierarchically organize *facets*. Unlike *files*, +*factes* don't only store a freeform *name*, there is also a dedicated *type* field associated with every *facet*, that +is explicitly designed to be understood and used by the system. -Despite the similarities, the semantics of this system are very different: -In mainstream filesystems, each *file* stands for itself only; -i.e. in a *directory*, no relationship between *files* is assumed by default, -and files are most of the time read or used outside of the context they exist in in the filesystem. +Despite the similarities, the semantics of this system are very different: In mainstream filesystems, each *file* stands +for itself only; i.e. in a *directory*, no relationship between *files* is assumed by default, and files are most of the +time read or used outside of the context they exist in in the filesystem. In mmmfs, a *facet* should only ever be considered an aspect of its *fileder*, and never as separate from it. -A *fileder* can contain multiple *facets*, but they are meant to be alternate or equivalent representations of the *fileder* itself. -Though for some uses it is required, software in general does not have to be directly aware of the *facets* existing within a *fileder*, -rather it assumes the presence of content in the representation that it requires, and simple requests it. -The *Type Coercion Engine* (see below) will then attempt to satisfy this request based on the *facets* that are in fact present. +A *fileder* can contain multiple *facets*, but they are meant to be alternate or equivalent representations of the +*fileder* itself. Though for some uses it is required, software in general does not have to be directly aware of the +*facets* existing within a *fileder*, rather it assumes the presence of content in the representation that it requires, +and simple requests it. The *Type Coercion Engine* (see below) will then attempt to satisfy this request based on the +*facets* that are in fact present. -Semantically a *fileder*, like a *directory*, also encompasses all the other *fileders* nested within it (recursively). -Since *fileders* are the primary unit of data to be operated upon, *fileder* nesting emerges as a natural way of structuring complex data, -both for access by the system and applications, as well as the user themself. +Semantically a *fileder*, like a *directory*, also encompasses all the other *fileders* nested within itself +(recursively). Since *fileders* are the primary unit of data to be operated upon, *fileder* nesting emerges as a natural +way of structuring complex data, both for access by the system and its components, as well as the user themself. ## the type system & coercion engine -As mentioned above, *facets* store data alongside its *type*, and when applications require data from a *fileder*, -they specify the *type* (or the list of *types*) that they require the type to be in. - -In the current iteration of the type system, types are simple strings of text and loosely based on MIME-types [TOOD: quote RFC?]. +As mentioned above, *facets* store data alongside its *type*, and when a component of the system requires data from a +*fileder*, it has to specify the *expected type* (or a list of these) that it requires the data to be in. The system +then attempts to coerce one of the existing facets into the *expected type*, if possible. This process can involve many +steps such as converting between similar file formats, running executable code stored in a facet, or fetching remote +content. The component that requested the data is isolated from this process and does not have to deal with any of the +details. + +In the current iteration of the type system, types are simple strings of text and loosely based on MIME-types. MIME types consist of a major- and minor category, and optionally a 'suffix'. Here are some common MIME-types that are also used in mmmfs: @@ -87,29 +94,29 @@ Here are some common MIME-types that are also used in mmmfs: - `image/png` - `image/jpeg` -While these types allow some amount of specifity, they fall short of describing their content especially in cases where formats overlap: -Source code is often distributed in `.tar.gz` archive files (directory-trees that are first bundled into an `application/x-tar` archive, -and then compressed into an `application/gzip` archive). -Using either of these two types is either incorrect or insufficient information to properly treat and extract the contained data. +While these types allow some amount of specifity, they fall short of describing their content especially in cases where +formats overlap: Source code for example is often distributed in `.tar.gz` archive files (directory-trees that are first +bundled into an `application/x-tar` archive, and then compressed into an `application/gzip` archive). Using either of +these two types is respectively incorrect or insufficient information to properly treat and extract the contained data. -To mitigate this problem, mmmfs *types* can be nested. This is denoted in mmmfs *type* strings using the `->` symbol, e.g. the mmmfs-types -`application/gzip -> application/tar -> dirtree` and `URL -> image/jpeg` describe a tar-gz-compressed directory tree and the URL linking to a JPEG-picture respectively. +To mitigate this problem, mmmfs *types* can be nested. This is denoted in mmmfs *type* strings using the `->` symbol, +e.g. the mmmfs *types* `application/gzip -> application/tar -> dirtree` and `URL -> image/jpeg` describe a +tar-gz-compressed directory tree and the URL linking to a JPEG-encoded picture respectively. Depending on the outer type this nesting can mean different things: for URLs the nested type is expected to be found after fetching the URL with HTTP, compression formats are expected to contain contents of the nested types, and executable formats are expected to output data of the nested type. -It is a lot more important to be able to accurately describe the type of a *facet* in mmmfs than in mainstream operating systems, -because while in the latter types are mostly used only associate an application that will then prompt the user about further steps, -mmmfs uses the *type* to automatically find one or more programs to execute to convert or transform the data stored in a *facet* -into the *type* required by the application. +It is a lot more important to be able to accurately describe the type of a *facet* in mmmfs than in mainstream operating +systems, because while in the latter types are mostly used only associate an application that will then prompt the user +for further steps if necessary, mmmfs uses the *type* to automatically find one or more programs to execute, in order to +convert or transform the data stored in a *facet* into the *type* required in the context where it was requested. -This process of *type coercion* uses a database of known *converts*, that can be applied to data. -Every *convert* consists of a description of the input *types* that it can accept, the output *type* it would produce for a given input type, -as well as the code for actually converting a given piece of data. -Simple *converts* may simply consist of a fixed in and output type, -such as for example this *convert* for rendering Markdown-encoded text to a HTML hypertext fragment: +This process of *type coercion* uses a database of known *converts* that can be applied to data. Every *convert* +consists of a description of the input *types* that it can accept, the output *type* it would produce for a given input +type, as well as the code for actually converting a given piece of data. Simple *converts* may simply consist of a fixed +in and output type, such as for example this *convert* for rendering Markdown-encoded text to a HTML hypertext fragment: { inp: 'text/markdown' @@ -129,8 +136,8 @@ Other *converts* on the other hand may accept a wide range of input types: This convert uses a Lua Pattern to specify that it can accept an URL to any type of image, and convert it to an HTML fragment. -By using the pattern substitution syntax provided by the Lua `string.gsub` function, -converts can also make the type they return depend on the input type, as is required often when nested types are unpacked: +By using the pattern substitution syntax provided by the Lua `string.gsub` function, converts can also make the type +they return depend on the input type, as is required often when nested types are unpacked: { inp: 'application/gzip -> (.*)' @@ -139,11 +146,11 @@ converts can also make the type they return depend on the input type, as is requ -- implementation stripped for brevity } -This *convert* accepts an `application/gzip` *type* wrapping any other *type*, and captures that nested type in a pattern group. -It then uses the substituion syntax to specify that nested type as the output of the conversion. +This *convert* accepts an `application/gzip` *type* wrapping any other *type*, and captures that nested type in a +pattern group. It then uses the substituion syntax to specify that nested type as the output of the conversion. For an input *type* of `application/gzip -> image/png` this *convert* would therefore generate the type `image/png`. -To further demonstrate the flexibility using this approach, consider this last example: +This last example further demonstrates the flexibility of this approach: { inp: 'text/moonscript -> (.*)' @@ -154,30 +161,31 @@ To further demonstrate the flexibility using this approach, consider this last e This *convert* transpiles MoonScript source-code into Lua source-code, while keeping the nested type (in this case the result expected when executing either script) the same. -In addition to the attributes shown above, every *convert* is also rated with a *cost* value. -The cost value is meant to roughly estimate both the cost (in terms of computing power) of the conversion, -as well as the accuracy or immediacy of the conversion. -For example, resizing an image to a lower size should have a high cost, because the process is computationally expensive, -but also because a smaller image represents the original image to a lesser degree. -Similarily, an URL to a piece of content is a less immediate representation than the content itself, -so the cost of a *convert* that simply generates the URL to a piece of data should be high even if the process is very cheap to compute. - -Cost is defined in this way to make sure that the result of a type-coercion operation reflects the content that was present as accurately as possible. -It is also important to prevent some nonsensical results from occuring, such as displaying a link to content instead of the content itself because -the link requires less steps to create than completely converting the content does. - -Type coercion is implemented using a general pathfinding algorithm, similar to A\*. -First, the set of given *types* is found by selecting all *facets* of the *fileder* that match the *name* given in the query. -The set of given *types* is marked in green in the following example graph. - -From there the algorithm recursively checks whether it can reach other types by applying all matching *converts* to the type -that is cheapest to reach, excluding any types that have already been exhaustively-searched in this way. -All types it finds, that have not yet been inserted into the set of given types are then added to the set, -so that they may be searched as well. - -The algorithm doesn't stop immediately after reaching a type from the result set, -it continues search until it either completely exhausts the result space, -or until all non-exhaustively searched paths are already higher than the maximum allowed path. -This ensures that the optimal path is found, even if a more expensive path is found more quickly initially. - -excerpt of the graph of conversion paths from two starting facets to mmm/dom +In addition to the attributes shown above, every *convert* is also rated with a *cost* value. The cost value is meant to +roughly estimate both the cost (in terms of computing power) of the conversion, as well as the accuracy or immediacy of +the conversion. For example, resizing an image to a lower size should have a high cost, because the process is +computationally expensive, but also because a smaller image represents the original image to a lesser degree. +Similarily, an URL to a piece of content is a less immediate representation than the content itself, so the cost of a +*convert* that simply generates the URL to a piece of data should be high even if the process is very cheap to compute. + +Cost is defined in this way to make sure that the result of a type-coercion operation reflects the content that was +present as accurately as possible. It is also important to prevent some nonsensical results from occuring, such as +displaying a link to content instead of the content itself because the link is cheaper to create than completely +converting the content does. + +Type coercion is implemented using a general pathfinding algorithm, based on *Dijkstra's Algorithm*. First, the set of given *types* is found by selecting all +*facets* of the *fileder* that match the *name* given in the query. The set of given *types* is marked in green in the +following example graph. +From there the algorithm recursively checks whether it can reach other *types* by applying all matching *converts* to +the *type* that is the cheapest to reach currently, excluding any *types* that have already been exhaustively-searched +in this way. All *types* found that have not yet been inserted into the set of given *types* are then added to the +set, so that they may be searched as well. + +The algorithm doesn't stop immediately after reaching a *type* from the result set, it continues search until it either +completely exhausts the result space, or until all non-exhaustively searched paths already have costs higher than the +allowed maximum. This ensures that the optimal path is found, even if a more expensive path is found more quickly +initially. + +excerpt of the graph of conversion paths from two starting facets to mmm/dom + diff --git a/root/articles/mmmfs/motivation/$order b/root/articles/mmmfs/motivation/$order index c327490..accfc0b 100644 --- a/root/articles/mmmfs/motivation/$order +++ b/root/articles/mmmfs/motivation/$order @@ -1 +1,2 @@ +app-types creative diff --git a/root/articles/mmmfs/motivation/app-types/text$markdown.md b/root/articles/mmmfs/motivation/app-types/text$markdown.md new file mode 100644 index 0000000..aac79d7 --- /dev/null +++ b/root/articles/mmmfs/motivation/app-types/text$markdown.md @@ -0,0 +1,3 @@ +While there can be a distinction between *Native Applications* and *Web Applications* or *Cloud Services*, the following +arguments apply to all different technicalal implementations of this same concept. The problems associated +specifically with Web- and Cloud-based application models will be discussed separately below. diff --git a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md index f0c2e6c..ab18726 100644 --- a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md @@ -7,37 +7,29 @@ application-centric design The majority of users interact with modern computing systems in the form of smartphones, laptops or desktop PCs, using the mainstream operating systems Apple iOS and Mac OS X, Microsoft Windows or Android. + All of these operating systems share the concept of *Applications* (or *Apps*) as one of the core pieces of their interaction model. Functionality and capabilities of the digital devices are bundled in, marketed, sold and distributed -as applications. +as applications. This focus on applications as the primary unit of systems can be seen as the root cause of multiple problems. - - -In addition, a lot of functionality is nowadays delivered in the form of *Web Apps* or *Cloud Services*, which share the -limitations of native applications in addition to more specific issues that will be discussed in a separate section -below. - -This focus on applications as the primary unit of systems can be seen as the root cause of multiple problems. - - -For one, since applications are the products companies produce, and software represents a market of users, +For one, since applications are produced by private companies on the software market, developers compete on features integrated into their applications. To stay relevant, monlithic software or software suites tend to accrete features rather then modularise and delegate to other software. This makes many software packages more complex and unintuitive than they need to be, and also cripples interoperability between applications and data formats. -Because applications are incentivised to keep customers, they make use of network effects to keep customers locked-in. -This often means re-implementing services and functionality that is already available to users, +Because (private) software developers are incentivised to keep customers, they make use of network effects to keep +customers locked-in. This often means re-implementing services and functionality that is already available to users, and integrating it directly in other applications or as a new product by the same organisation. -While this strategy helps big software companies retain customers, it harms the users, who have to navigate a complex +While this strategy helps big software companies retain customers, it harms users, who have to navigate a complex landscape of multiple incompatible, overlapping and competing software ecosystems. Data of the same kind, a rich-text document for example, can be shared easily within the software systems of a certain -manufacturer, and with other users of the same, but sharing with users of a competing system, even if it has almost the +manufacturer and with other users of the same, but sharing with users of a competing system, even if it has almost the exact same capabilities, can often be problematic. -Another issue is that due to the technical challenges of building tools in this system, applications are designed and +Another issue is that due to the technical challenges of development in the this paradigm, applications are designed and developed by experts in application development, rather than experts in the domain of the tool. While developers may -solicit feedback, advice and ideas from domain experts, communication is a barrier. Additionally, domain experts are +solicit feedback, advice, and ideas from domain experts, communication is a barrier. Additionally, domain experts are generally unfamiliar with the technical possibilities, and may therefore not be able to express feedback that would lead to more significant advances. @@ -48,7 +40,7 @@ The application-centric computing metaphor treats applications as black boxes, a customize or modify the behaviour of apps, intentionally obscuring the inner-workings of applications and completely cutting users off from this type of ownership over their technology. While the trend seems to be to further hide the way desktop operating systems work, -mobile systems like Apple's *iOS* already started out as such so-called *walled gardens*. +mobile systems like Apple's *iOS* already started out as such *walled gardens*. cloud computing --------------- @@ -68,15 +60,15 @@ continue servicing a customer, the users data may be irrecoverably lost (or acce consequences, especially for professional users, for whom an inability to access their tools or their cloud-stored data can pose an existential threat. -inert data (formats) --------------------- +inert data (and data formats) +----------------------------- Cragg coins the term "inert data" for the data -created, and left behind, by apps and applications in the computing model that is currently prevalent: Most data today +created and left behind by apps and applications in the computing model that is currently prevalent: Most data today is either intrinsically linked to one specific application, that controls and limits access to the actual information, -or even worse, stored in the cloud where users have no direct access at all and depend soley on online tools that -require a stable network connection and a modern browser, and that could be modified, removed or otherwise negatively -impacted at any moment. +or, even worse, stored in the cloud where users have no direct access at all. In the latter case users depend soley on +online tools that require a stable network connection and a modern browser and could be modified, removed, or otherwise +negatively impacted at any moment. Aside from being inaccesible to users, the resulting complex proprietary formats are also opaque and useless to other applications and the operating system, which often is a huge missed opportunity: @@ -98,9 +90,9 @@ individual file stands for itself. Grouping of files in folders is allowed as a applications only ever concern themselves with a single file at a time, independent of the context the file is stored in in the filesystem. -Data rarely really fits this metaphora of individual files very well, and even when it does, it is rarely exposed to +Data rarely really fits this concept of individual files very well, and even when it does, it is rarely exposed to the user that way: The 'Contacts' app on a mobile phone for example does not store each contacts's information in a -separate 'file' (as the metaphora may suggest initially), but rather keeps all information in a single database file, +separate 'file' (as the word may suggest initially), but rather keeps all information in a single database file, which is hidden away from the user. Consequently, access to the information contained in the database is only enabled through the contacts application's graphical interface, and not through other applications that generically operate on files. @@ -111,21 +103,25 @@ brainstorm, many might be tempted to open an application like *Microsoft Word* o document there. Both *Photoshop* files and *Word* documents are capable of containing texts and images, but when such content is copied into them from external sources, such as other files on the same computer, or quotes and links from the internet, these relationships are irrevocably lost. As illustrated above, additionally, it becomes a lot harder to -edit the content once it is aggregated as well. To choose an application for this task is a trade-off, because in -applications primarily designed for word processing, arranging content visually is harder and image editing and video -embedding options are limited, while tools better suited to these tasks lack nuance when working with text. - -Rather than face this dilemma, a more sensible system could leave the task of positioning and aggregating content of -different types to one software component, while multiple different software components can be responsible for editing -the individual pieces of content, so that the most appropriate one can be chosen for each element. +edit the content once it is aggregated. To choose an application for this task is a hard trade-off to make, because in +applications primarily designed for word processing, arranging content visually is hard to do, and image editing and +video embedding options are limited, while tools better suited to these tasks lack nuance when working with text. + +To avoid facing this dilemma, a more sensible system could leave the task of positioning and aggregating content of +different types to one software component, while multiple different software components could be responsible for editing +the individual pieces of content, so that the most appropriate one can be chosen for each element. While creating the +technological interface between these components is certainly a challenge, the resulting system would greatly benefit +from the exponentially-growing capabilties resulting from the modular reuse of components across many contexts: A rich +text editor component could be used for example not just in a mixed media collection as proposed above, but also for +an email editor or the input fields in a browser.

-To summarize, for various reasons, the metaphors and interfaces of computing interfaces today prevent users from deeply -understanding the software they use and the data they own, from customizing and improving their experience and +To summarize, for various reasons, the metaphors and driving concepts of computing interfaces today prevent users from +deeply understanding the software they use and the data they own, from customizing and improving their experience and interactions, and from properly owning, contextualising and connecting their data. -Interestingly, these deficits do not appear throughout the history of todays computing systems, but are based in rather +Interestingly, these deficits do not appear throughout the history of today's computing systems, but are based in rather recent developments in the field. In fact the most influental systems in the past aspired to the polar opposites, as i will show in the next section. diff --git a/root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon index 0dac590..615075a 100644 --- a/root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon +++ b/root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon @@ -4,48 +4,23 @@ -- resolves to a value of type mmm/dom => html = require 'mmm.dom' - import article, h1, h2, h3, section, p, div, a, sup, ol, li, span, code, pre, br from html + import article, h1, p, div from html import moon from (require 'mmm.highlighting').languages - article with _this = class: 'sidenote-container', style: { 'max-width': '640px', 'line-height': '1.5' } + article with _this = class: 'sidenote-container spacious', style: { 'max-width': '640px', 'line-height': '1.5' } append = (a) -> table.insert _this, a - footnote, getnotes = do - local * - notes = {} + append div { + h1 'Empowered End-User Computing', style: { 'margin-bottom': 0 } + p { + style: + 'margin-top': 0 + 'padding-bottom': '0.2em' + 'border-bottom': '1px solid black' - id = (i) -> "footnote-#{i}" - - footnote = (stuff) -> - i = #notes + 1 - notes[i] = stuff - sup a "[#{i}]", style: { 'text-decoration': 'none' }, href: '#' .. id i - - footnote, -> - args = for i, note in ipairs notes - li (span (tostring i), id: id i), ': ', note - notes = {} - table.insert args, style: { 'list-style': 'none', 'font-size': '0.8em' } - ol table.unpack args - - append h1 'Empowered End-User Computing', style: { 'margin-bottom': 0 } - append p "A Historical Investigation and Development of a File-System-Based Environment", style: { 'margin-top': 0, 'padding-bottom': '0.2em', 'border-bottom': '1px solid black' } - - -- render a preview block - do_section = (child) -> - -- get 'title' as 'text/plain' (error if no value or conversion possible) - title = (child\get 'title: text/plain') or child\gett 'name: alpha' - - -- get 'preview' as a DOM description (nil if no value or conversion possible) - content = (child\get 'preview: mmm/dom') or child\get 'mmm/dom' - - section { - h3 title, style: { margin: 0, cursor: 'pointer' }, onclick: -> BROWSER\navigate child.path - content or span '(no renderable content)', style: { color: 'red' }, + "A Historical Investigation and Development of a File-System-Based Environment" } + } for child in *@children append (child\get 'print: mmm/dom') or (child\gett 'mmm/dom') - -- do_section child - - append getnotes! diff --git a/root/articles/mmmfs/references/$order b/root/articles/mmmfs/references/$order index 01b0c04..1e250b7 100644 --- a/root/articles/mmmfs/references/$order +++ b/root/articles/mmmfs/references/$order @@ -16,3 +16,5 @@ acm-dl aspect-ratios alternatives-to-trees transclusion +mime-types +dijkstra diff --git a/root/articles/mmmfs/references/dijkstra/text$bibtex b/root/articles/mmmfs/references/dijkstra/text$bibtex new file mode 100644 index 0000000..c38a470 --- /dev/null +++ b/root/articles/mmmfs/references/dijkstra/text$bibtex @@ -0,0 +1,17 @@ +@article{10.1007/BF01386390, + author = {Dijkstra, Edsger W.}, + title = {A Note on Two Problems in Connexion with Graphs}, + year = {1959}, + issue_date = {December 1959}, + publisher = {Springer-Verlag}, + address = {Berlin, Heidelberg}, + volume = {1}, + number = {1}, + issn = {0029-599X}, + url = {https://doi.org/10.1007/BF01386390}, + doi = {10.1007/BF01386390}, + journal = {Numer. Math.}, + month = dec, + pages = {269–271}, + numpages = {3} +} diff --git a/root/articles/mmmfs/references/mime-types/text$bibtex b/root/articles/mmmfs/references/mime-types/text$bibtex new file mode 100644 index 0000000..c49b553 --- /dev/null +++ b/root/articles/mmmfs/references/mime-types/text$bibtex @@ -0,0 +1,14 @@ +@article{rfc6838, + series = {Request for Comments}, + number = 6838, + howpublished = {RFC 6838}, + publisher = {Internet Engineering Task Force}, + doi = {10.17487/RFC6838}, + url = {https://tools.ietf.org/html/rfc6838}, + author = {Freed, Ned and Klensin, John C. and Hansen, Tony}, + title = {Media Type Specifications and Registration Procedures}, + pagetotal = 32, + year = 2013, + month = jan, + abstract = {This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.}, +} diff --git a/root/articles/mmmfs/statement-of-originality/text$html+frag.html b/root/articles/mmmfs/statement-of-originality/text$html+frag.html new file mode 100644 index 0000000..d5fd76f --- /dev/null +++ b/root/articles/mmmfs/statement-of-originality/text$html+frag.html @@ -0,0 +1,13 @@ +

Statement of Originality

+This is to certify that the content of this project, documentation and thesis is my own work. It +has not been submitted for any other degree or other purposes. I certify that the intellectual +content of my submission is the product of my own work and that all the assistance received in +preparing it as well as all sources used have been properly acknowledged. +

+ +

+Sol Bekic +

diff --git a/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon index 1939042..89c9a7d 100644 --- a/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon +++ b/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon @@ -4,48 +4,24 @@ -- resolves to a value of type mmm/dom => html = require 'mmm.dom' - import article, h1, h2, h3, section, p, div, a, sup, ol, li, span, code, pre, br from html + import article, h1, p, div from html import moon from (require 'mmm.highlighting').languages - article with _this = class: 'sidenote-container', style: { 'max-width': '640px', 'line-height': '1.5' } + article with _this = class: 'sidenote-container spacious', style: { 'max-width': '640px', 'line-height': '1.5' } append = (a) -> table.insert _this, a - footnote, getnotes = do - local * - notes = {} + append div { + class: 'screen-only' + h1 'Empowered End-User Computing', style: { 'margin-bottom': 0 } + p { + style: + 'margin-top': 0 + 'padding-bottom': '0.2em' + 'border-bottom': '1px solid black' - id = (i) -> "footnote-#{i}" - - footnote = (stuff) -> - i = #notes + 1 - notes[i] = stuff - sup a "[#{i}]", style: { 'text-decoration': 'none' }, href: '#' .. id i - - footnote, -> - args = for i, note in ipairs notes - li (span (tostring i), id: id i), ': ', note - notes = {} - table.insert args, style: { 'list-style': 'none', 'font-size': '0.8em' } - ol table.unpack args - - append h1 'Empowered End-User Computing', style: { 'margin-bottom': 0 } - append p "A Historical Investigation and Development of a File-System-Based Environment", style: { 'margin-top': 0, 'padding-bottom': '0.2em', 'border-bottom': '1px solid black' } - - -- render a preview block - do_section = (child) -> - -- get 'title' as 'text/plain' (error if no value or conversion possible) - title = (child\get 'title: text/plain') or child\gett 'name: alpha' - - -- get 'preview' as a DOM description (nil if no value or conversion possible) - content = (child\get 'preview: mmm/dom') or child\get 'mmm/dom' - - section { - h3 title, style: { margin: 0, cursor: 'pointer' }, onclick: -> BROWSER\navigate child.path - content or span '(no renderable content)', style: { color: 'red' }, + "A Historical Investigation and Development of a File-System-Based Environment" } + } for child in *@children append child\gett 'mmm/dom' - -- do_section child - - append getnotes! diff --git a/root/articles/mmmfs/title/text$html+frag.html b/root/articles/mmmfs/title/text$html+frag.html new file mode 100644 index 0000000..1b0bf03 --- /dev/null +++ b/root/articles/mmmfs/title/text$html+frag.html @@ -0,0 +1,21 @@ +

Empowered End-User Computing

+ A Historical Investigation and Development of a File-System-Based Environment +

+ Sol Bekic
+ Student ID 11114279
+ sol.bekic+ba@s-ol.nu +

+ written in the Winter Term 2019/20
+ for BA Digital Games
+ at Cologne Game Lab / TH Köln +

supervised by Prof. Dr. Gundolf S. Freyermuth

submitted on 2020-01-07

-- cgit v1.2.3 From 2c3977673b94f67779cc439b7b1460f08d8d38df Mon Sep 17 00:00:00 2001 From: s-ol Date: Tue, 31 Dec 2019 15:11:47 +0100 Subject: table-of-contents, reference order --- root/articles/mmmfs/$order | 3 +- root/articles/mmmfs/ba_log/intro: text$markdown.md | 4 + .../print: text$moonscript -> fn -> mmm$dom.moon | 3 +- .../ba_log/text$moonscript -> fn -> mmm$dom.moon | 3 +- root/articles/mmmfs/ba_log/title: text$plain | 1 - .../mmmfs/conclusion/text$markdown+sidenotes.md | 3 +- .../mmmfs/evaluation/text$markdown+sidenotes.md | 23 +++--- .../implementation: text$markdown+sidenotes.md | 88 +++++++++++++++++++++ .../examples/intro: text$markdown+sidenotes.md | 92 +--------------------- .../examples/text$moonscript -> fn -> mmm$dom.moon | 14 +--- .../mmmfs/framework/text$markdown+sidenotes.md | 19 +++-- .../text$markdown+sidenotes.md | 3 +- root/articles/mmmfs/mmmfs/$order | 1 - .../mmmfs/mmmfs/confusion/text$markdown.md | 5 -- .../mmmfs/mmmfs/text$markdown+sidenotes.md | 17 ++-- .../mmmfs/motivation/text$markdown+sidenotes.md | 19 +++-- root/articles/mmmfs/references/$order | 28 +++---- root/articles/mmmfs/references/adobe/text$bibtex | 1 + .../mmmfs/references/ios-files/text$bibtex | 6 -- .../articles/mmmfs/references/renaming/text$bibtex | 6 ++ .../text$moonscript -> fn -> mmm$dom.moon | 2 +- .../statement-of-originality/text$html+frag.html | 2 +- .../mmmfs/table-of-contents/text$html+frag.html | 89 +++++++++++++++++++++ .../mmmfs/text$moonscript -> fn -> mmm$dom.moon | 1 - 24 files changed, 256 insertions(+), 177 deletions(-) create mode 100644 root/articles/mmmfs/ba_log/intro: text$markdown.md delete mode 100644 root/articles/mmmfs/ba_log/title: text$plain create mode 100644 root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md delete mode 100644 root/articles/mmmfs/mmmfs/confusion/text$markdown.md delete mode 100644 root/articles/mmmfs/references/ios-files/text$bibtex create mode 100644 root/articles/mmmfs/references/renaming/text$bibtex create mode 100644 root/articles/mmmfs/table-of-contents/text$html+frag.html (limited to 'root') diff --git a/root/articles/mmmfs/$order b/root/articles/mmmfs/$order index 10dcf5c..563d544 100644 --- a/root/articles/mmmfs/$order +++ b/root/articles/mmmfs/$order @@ -1,5 +1,6 @@ title abstract +table-of-contents motivation historical-approaches framework @@ -8,5 +9,5 @@ examples evaluation conclusion references -statement-of-originality ba_log +statement-of-originality diff --git a/root/articles/mmmfs/ba_log/intro: text$markdown.md b/root/articles/mmmfs/ba_log/intro: text$markdown.md new file mode 100644 index 0000000..37366cf --- /dev/null +++ b/root/articles/mmmfs/ba_log/intro: text$markdown.md @@ -0,0 +1,4 @@ +The following pages document the development of the `mmmfs` system described above in the form of a project log. +Please note that the log has been written primarily for viewing using a web browser, and as such makes extensive use of +hyperlinking, and also includes some videos that cannot be reproduced in print. It is therefore recommended to view the +live version of the log online at the following address: [s-ol.nu/ba/log](https://s-ol.nu/ba/log). 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 d23edbb..97a6283 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,8 @@ import ropairs from require 'mmm.ordered' div { class: 'print-ownpage' - h1 link_to @, "appendix: project 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 37ffc78..bd2859d 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,8 @@ import ropairs from require 'mmm.ordered' => div { - h1 link_to @, "appendix: project log" + h1 (link_to @, "appendix: project log"), id: 'ba-log' + @gett 'intro: mmm/dom' ul do posts = for post in *@children continue if post\get 'hidden: bool' diff --git a/root/articles/mmmfs/ba_log/title: text$plain b/root/articles/mmmfs/ba_log/title: text$plain deleted file mode 100644 index a440bf3..0000000 --- a/root/articles/mmmfs/ba_log/title: text$plain +++ /dev/null @@ -1 +0,0 @@ -project log diff --git a/root/articles/mmmfs/conclusion/text$markdown+sidenotes.md b/root/articles/mmmfs/conclusion/text$markdown+sidenotes.md index 45d3bdf..0780b23 100644 --- a/root/articles/mmmfs/conclusion/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/conclusion/text$markdown+sidenotes.md @@ -1,4 +1,3 @@ -conclusion -========== +# 7. conclusion

[section under construction]

diff --git a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md index 1c8fda7..70b8df5 100644 --- a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md @@ -1,11 +1,10 @@ -evaluation -========== +# 6. evaluation -## examples +## 6.1 examples In this section I will take a look at the implementations of the example for the use cases outlined above, and evaluate them with regard to the framework derived in the corresponding section above. -### publishing and blogging +### 6.1.1 publishing and blogging Since mmmfs has grown out of the need for a versatile CMS for a personal publishing website, 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: @@ -25,7 +24,7 @@ Another issue is that the system is currently based on the presumption that cont separately from its parent and context in most cases. This has made the implementation of sidenotes less idiomatic than initially anticipated. -### pinwall +### 6.1.2 pinwall The pinwall example shows some strenghts 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. @@ -40,7 +39,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. -### slideshow +### 6.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: @@ -71,13 +70,13 @@ 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. -## general concerns +## 6.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. Some of these have been anticipated for some time and concrete research directions for solutions are apparent, while others may be intrinsic limitations in the approach taken. -### global set of converts +### 6.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. @@ -98,7 +97,7 @@ further up in the tree, for example to specialize types based on their context i The biggest downside to this approach would be that it presents another pressure factor for, while also reincforcing, the hierarchical organization of data, thereby exacerbating the limits of hierarchical structures. -### code outside of the system +### 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 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 @@ -115,7 +114,7 @@ for the global set of *converts* (see above), as well as the layout used to rend 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. -### type system +### 6.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, @@ -127,7 +126,7 @@ but others could use this information to generate lower-resolution 'thumbnails' Using these mechanisms for example images could be requested with a maximum-resolution constraint to save on bandwidth when embedded in other documents. -### type-coercion +### 6.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. @@ -142,7 +141,7 @@ as well as making this display interactive to encourage experimentation with cus Emphasising 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. -### editing +### 6.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. diff --git a/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md b/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md new file mode 100644 index 0000000..d32b0db --- /dev/null +++ b/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md @@ -0,0 +1,88 @@ +## 5.1 publishing and blogging +### 5.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: +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, +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 mmm. + +### 5.1.2 scientific 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, +since it does not support interaction. +

+ +Scientific 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 +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 scientific 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 +BibTeX format for describing citations. Converts have been implemented for the `text/bibtex` +type to convert to a full reference format (to `mmm/dom`) and to an inline side-note reference +(`mmm/dom+link`) that can be transcluded using the `` pseudo-tag. + +For convenience, a convert from the `URL -> cite/acm` type has been provided to `URL -> text/bibtex`, +which generates links to the ACM Digital Library +API for accessing BibTeX citations for documents in the library. This means that it is enough to store the link to the +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 spacially so that they can be viewed +at a glance or organized into different contexts etc. +Such a pinwall could serve for example to organise references to articles, +to collect visual inspiration for a moodboard 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, +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: +`pinwall_info: text/json`. Such a facet is set on each child and read whenever the script is called +to render the children, plugging the values within the facet into the visual styling of the document. + +The script can also set event handlers that react to user input while the document is loaded, +and allow the user to reposition and resize the individual pinwall items by clicking and dragging +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 +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 +advanced (and rewound) one by one using keypresses. + +The implementation of this is rather straightforward as well. +The slideshow as a whole becomes a fileder with a script that generates a designated viewport rectangle, +as well as a control interface with keys for advancing the active slide. +It also allows putting the browser into fullscreen mode to maximise screenspace and remove visual elements +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. +Once the current slide is changed, the next embedded child is simply chosen. + + diff --git a/root/articles/mmmfs/examples/intro: text$markdown+sidenotes.md b/root/articles/mmmfs/examples/intro: text$markdown+sidenotes.md index 709da5c..7b54d95 100644 --- a/root/articles/mmmfs/examples/intro: text$markdown+sidenotes.md +++ b/root/articles/mmmfs/examples/intro: text$markdown+sidenotes.md @@ -1,94 +1,8 @@ -# examples +# 5. example use-cases To illustrate the capabilities of the proposed system, and to compare the results with the framework introduced above, a number of example use cases have been chosen and implemented from the perspective of a user. In the following section I will introduce these use cases and briefly summarize the implementation approach in terms of the capabilities of the proposed system. -## publishing and blogging -### 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: -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, -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 mmm. - -### scientific 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, -since it does not support interaction. -

- -Scientific 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 -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 scientific 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 -BibTeX format for describing citations. Converts have been implemented for the `text/bibtex` -type to convert to a full reference format (to `mmm/dom`) and to an inline side-note reference -(`mmm/dom+link`) that can be transcluded using the `` pseudo-tag. - -For convenience, a convert from the `URL -> cite/acm` type has been provided to `URL -> text/bibtex`, -which generates links to the ACM Digital Library -API for accessing BibTeX citations for documents in the library. This means that it is enough to store the link to the -ACM DL entry in mmmfs, and the reference will automatically be fetched, and therefore stay up to date with potential -remote corrections. - -## 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 spacially so that they can be viewed -at a glance or organized into different contexts etc. -Such a pinwall could serve for example to organise references to articles, -to collect visual inspiration for a moodboard 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, -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: -`pinwall_info: text/json`. Such a facet is set on each child and read whenever the script is called -to render the children, plugging the values within the facet into the visual styling of the document. - -The script can also set event handlers that react to user input while the document is loaded, -and allow the user to reposition and resize the individual pinwall items by clicking and dragging -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. - -## 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 -advanced (and rewound) one by one using keypresses. - -The implementation of this is rather straightforward as well. -The slideshow as a whole becomes a fileder with a script that generates a designated viewport rectangle, -as well as a control interface with keys for advancing the active slide. -It also allows putting the browser into fullscreen mode to maximise screenspace and remove visual elements -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. -Once the current slide is changed, the next embedded child is simply chosen. - - +The online version is available at [s-ol.nu/ba](https://s-ol.nu/ba). +The following examples can be viewed and inspected in the interactive version online: diff --git a/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon index 1401e95..6c47270 100644 --- a/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon +++ b/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon @@ -31,15 +31,7 @@ li link_to child - examples = div { - style: - position: 'relative' - 'margin-top': '4rem' + examples = ul for child in *@children + preview child - div "The online version is available at ", (a "s-ol.nu/ba", href: 'https://s-ol.nu/ba'), ".", class: 'sidenote' - "The following examples can be viewed and inspected in the interactive version online:" - ul for child in *@children - preview child - } - - div (@gett 'intro: mmm/dom'), examples + div (@gett 'intro: mmm/dom'), examples, (@gett 'implementation: mmm/dom') diff --git a/root/articles/mmmfs/framework/text$markdown+sidenotes.md b/root/articles/mmmfs/framework/text$markdown+sidenotes.md index f62c581..81acb02 100644 --- a/root/articles/mmmfs/framework/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/framework/text$markdown+sidenotes.md @@ -1,12 +1,11 @@ -evaluation framework -==================== +# 3. evaluation framework In the following section, I will collect approaches and reviews of different end-user software systems from current literature, as well as derive and present my own requirements and guiding principles for the development of a new system. -qualities ---------- +3.1 qualities of successful end-user computing +---------------------------------------------- *Ink and Switch* suggest three qualities for tools striving to support end-user programming: @@ -26,8 +25,8 @@ very abstract. The following properties are therefore derived as more concrete p constraints: namely the construction of a system for end-users to keep, structure and display personal information and thoughts. -modularity ----------- +3.2 modularity +-------------- The *UNIX Philosophy* describes the software design paradigm pioneered in the creation of the Unix operating system at the AT&T Bell Labs research center in the 1960s. The @@ -50,8 +49,8 @@ alternate software at any time. Settling on a specific modular design model, and reifying other components of a system in terms of it, also corresponds directly to the concept of *Embodiment* described by Ink & Switch. -content transclusion --------------------- +3.3 content transclusion +------------------------ The strengths of modular architectures should similarily extend also into the way the system will be used by users. If users are to store their information and customized behaviour in such an architecture, then powerful tools need to be @@ -76,8 +75,8 @@ This ability should be integrated deeply into the system, so that data can be tr storage conditions, with as little caveats as possible. In particular, the interactions of remote data access and content transclusion should be paid attention to and taken into consideration for a system's design. -end-user programming --------------------- +3.4 end-user programming +------------------------ In order to provide users full access to their information as well as the computational infrastructure, users need to be able to finely customize and reorganize the smallest pieces to suit their own purposes, diff --git a/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md b/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md index 8829f69..812d751 100644 --- a/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md @@ -1,5 +1,4 @@ -historical approaches -===================== +# 2. historical approaches Two of the earliest holistic computing systems, the Xerox Alto and Xerox Star, both developed at Xerox PARC and introduced in the 70s and early 80s, pioneered not only graphical user-interfaces, but also the "Desktop Metaphor". diff --git a/root/articles/mmmfs/mmmfs/$order b/root/articles/mmmfs/mmmfs/$order index ec11aa6..5a5d5ab 100644 --- a/root/articles/mmmfs/mmmfs/$order +++ b/root/articles/mmmfs/mmmfs/$order @@ -1,4 +1,3 @@ -confusion type_coercion_graph tree_mmmfs tree_mainstream diff --git a/root/articles/mmmfs/mmmfs/confusion/text$markdown.md b/root/articles/mmmfs/mmmfs/confusion/text$markdown.md deleted file mode 100644 index 55fe833..0000000 --- a/root/articles/mmmfs/mmmfs/confusion/text$markdown.md +++ /dev/null @@ -1,5 +0,0 @@ -For example, the difference between changing a file extension and converting a file between two formats is often unclear -to users, as evident from questions like this: -Why is it possible to convert a file just by renaming it?, https://askubuntu.com/q/166602 from 2019-12-18 - diff --git a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md index c2bbee5..28030d7 100644 --- a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md @@ -1,5 +1,4 @@ -mmmfs -===== +# 4. mmmfs `mmmfs` is a newly developed personal data storage and processing system. It was developed first as a tool for generating static websites, but has been extended with live interaction and introspection, as well as embedded @@ -13,7 +12,7 @@ seemlessly extended and molded to the users needs. The abstraction of data types is accomplished using two major components, the *Type System and Coercion Engine* and the *Fileder Unified Data Model* for unified data storage and access. -## the fileder unified data model +## 4.1 the fileder unified data model The Fileder Model is the underlying unified data storage model. Like many data storage models it is based fundamentally on the concept of a hierarchical tree-structure. @@ -42,16 +41,18 @@ Some notable mechanism are: It should be clear already from this short list that to mainstream operating systems, as well as the applications running on them, the format of a file is almost completely unknown and at best educated guesses can be made. - Because these various mechanisms are applied at different times by the operating system and applications, it is possible for files to be labelled or considered as being in different formats at the same time by different components of the system. -This leads to confusion about the factual format of data among users, but can also pose a serious security risk: +This leads to confusion about the factual format of data among usersFor example, the difference between changing a file extension and converting +a file between two formats is often unclear to users, as evident from questions like this: , but can +also pose a serious security risk: Under some circumstances it is possible that a file contains maliciously-crafted code and is treated as an executable by one software component, while a security mechanism meant to detect such code determines the same file to be a -legitimate image (the file may in fact be valid -in both formats). +legitimate image +(the file may in fact be valid in both formats). In mmmfs, the example above might look like this instead: schematic view of an example mmmfs tree @@ -76,7 +77,7 @@ Semantically a *fileder*, like a *directory*, also encompasses all the other *fi (recursively). Since *fileders* are the primary unit of data to be operated upon, *fileder* nesting emerges as a natural way of structuring complex data, both for access by the system and its components, as well as the user themself. -## the type system & coercion engine +## 4.2 the type system & coercion engine As mentioned above, *facets* store data alongside its *type*, and when a component of the system requires data from a *fileder*, it has to specify the *expected type* (or a list of these) that it requires the data to be in. The system then attempts to coerce one of the existing facets into the *expected type*, if possible. This process can involve many diff --git a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md index ab18726..9bfdea5 100644 --- a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md @@ -1,8 +1,7 @@ -motivation -========== +# 1. motivation -application-centric design --------------------------- +1.1 application-centric design +------------------------------ The majority of users interact with modern computing systems in the form of smartphones, laptops or desktop PCs, using the mainstream operating systems Apple iOS and Mac OS X, Microsoft Windows or Android. @@ -42,8 +41,8 @@ completely cutting users off from this type of ownership over their technology. hide the way desktop operating systems work, mobile systems like Apple's *iOS* already started out as such *walled gardens*. -cloud computing ---------------- +1.2 cloud computing +------------------- *Web Apps* often offer similar functionality to other applications, but are subject to additional limitations: In most cases, they are only accessible or functional in the presence of a stable internet connection, @@ -60,8 +59,8 @@ continue servicing a customer, the users data may be irrecoverably lost (or acce consequences, especially for professional users, for whom an inability to access their tools or their cloud-stored data can pose an existential threat. -inert data (and data formats) ------------------------------ +1.3 inert data (and data formats) +--------------------------------- Cragg coins the term "inert data" for the data created and left behind by apps and applications in the computing model that is currently prevalent: Most data today @@ -82,8 +81,8 @@ into the .docx document. If the word-processing application supports this, the o otherwise the user may have to remove the old image, insert the new one and carefully ensure that the positioning in the document remains intact. -disjointed filesystems ----------------------- +1.4 disjointed filesystems +-------------------------- The filesystems and file models used on modern computing devices generally operate on the assumption that every individual file stands for itself. Grouping of files in folders is allowed as a convenience for users, but most diff --git a/root/articles/mmmfs/references/$order b/root/articles/mmmfs/references/$order index 1e250b7..f50f166 100644 --- a/root/articles/mmmfs/references/$order +++ b/root/articles/mmmfs/references/$order @@ -1,20 +1,20 @@ +poc-or-gtfo +aspect-ratios +memex appliances -osx-files -ios-files super-powers -adobe +dijkstra +subtext +mime-types +alternatives-to-trees xerox-star -memex -hypercard -wikipedia unix -subtext +transclusion +adobe +acm-dl +hypercard inkandswitch linux-exec -poc-or-gtfo -acm-dl -aspect-ratios -alternatives-to-trees -transclusion -mime-types -dijkstra +wikipedia +osx-files +renaming diff --git a/root/articles/mmmfs/references/adobe/text$bibtex b/root/articles/mmmfs/references/adobe/text$bibtex index 3a83038..fccef37 100644 --- a/root/articles/mmmfs/references/adobe/text$bibtex +++ b/root/articles/mmmfs/references/adobe/text$bibtex @@ -2,6 +2,7 @@ title = {Adobe is cutting off users in Venezuela due to US sanctions}, url = {https://www.theverge.com/2019/10/7/20904030/adobe-venezuela-photoshop-behance-us-sanctions}, publisher = {The Verge}, + author = {Lee, Dami}, year = {2019}, visited = {2019-12-18}, } diff --git a/root/articles/mmmfs/references/ios-files/text$bibtex b/root/articles/mmmfs/references/ios-files/text$bibtex deleted file mode 100644 index 7ec911c..0000000 --- a/root/articles/mmmfs/references/ios-files/text$bibtex +++ /dev/null @@ -1,6 +0,0 @@ -@online{ios:files, - title = {Use the Files app on your iPhone, iPad, or iPod touch}, - url = {https://support.apple.com/en-us/HT206481}, - publisher = {Apple}, - visited = {2019-12-27}, -} diff --git a/root/articles/mmmfs/references/renaming/text$bibtex b/root/articles/mmmfs/references/renaming/text$bibtex new file mode 100644 index 0000000..a4aa714 --- /dev/null +++ b/root/articles/mmmfs/references/renaming/text$bibtex @@ -0,0 +1,6 @@ +@online{renaming, + title = {Why is it possible to convert a file just by renaming it?}, + url = {https://askubuntu.com/q/166602}, + publisher = {askubuntu.com}, + visited = {2019-12-18}, +} diff --git a/root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon index 59b5c54..7d0622c 100644 --- a/root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon +++ b/root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon @@ -5,7 +5,7 @@ refs = for ref in *@children li ref\gett 'mmm/dom' div { - h1 "references" + h1 "references", id: 'references' ol with refs refs.style = 'line-height': 'normal' } diff --git a/root/articles/mmmfs/statement-of-originality/text$html+frag.html b/root/articles/mmmfs/statement-of-originality/text$html+frag.html index d5fd76f..d6dcbc0 100644 --- a/root/articles/mmmfs/statement-of-originality/text$html+frag.html +++ b/root/articles/mmmfs/statement-of-originality/text$html+frag.html @@ -1,5 +1,5 @@

Statement of Originality

statement of originality

This is to certify that the content of this project, documentation and thesis is my own work. It has not been submitted for any other degree or other purposes. I certify that the intellectual diff --git a/root/articles/mmmfs/table-of-contents/text$html+frag.html b/root/articles/mmmfs/table-of-contents/text$html+frag.html new file mode 100644 index 0000000..f349c1e --- /dev/null +++ b/root/articles/mmmfs/table-of-contents/text$html+frag.html @@ -0,0 +1,89 @@ + +

abstract
table of contents
1. motivation

1.1 application-centric design
1.2 cloud computing
1.3 inert data (and data formats)
1.4 disjointed filesystems

2. historical approaches
3. evaluation framework

3.1 qualities of successful end-user computing
3.2 modularity
3.3 content transclusion
3.4 end-user programming

4. mmmfs

4.1 the fileder unified data model
4.2 the type system & coercion engine

5. example use-cases

5.1 publishing and blogging

5.1.1 blogging
5.1.2 scientific publishing

5.2 pinwall
5.3 slideshow

6. evaluation

6.1 examples

6.1.1 publishing and blogging
6.1.2 pinwall
6.1.3 slideshow

6.2 general concerns

6.2.1 global set of converts
6.2.2 code outside of the system
6.2.3 type system
6.2.4 type-coercion
6.2.5 in-system editing

7. conclusion
references
appendix: project log
statement of originality

diff --git a/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon index 89c9a7d..6c5b1d3 100644 --- a/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon +++ b/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon @@ -11,7 +11,6 @@ append = (a) -> table.insert _this, a append div { - class: 'screen-only' h1 'Empowered End-User Computing', style: { 'margin-bottom': 0 } p { style: -- cgit v1.2.3 From 719fe5d1a2f8b2d1e2c58b7aed18e6062656ca90 Mon Sep 17 00:00:00 2001 From: s-ol Date: Tue, 31 Dec 2019 18:40:54 +0100 Subject: spellcheck --- root/articles/mmmfs/ba_log/2019-10-10/text$markdown.md | 2 +- root/articles/mmmfs/ba_log/2019-10-29/text$markdown.md | 2 +- .../mmmfs/evaluation/text$markdown+sidenotes.md | 10 +++++----- .../implementation: text$markdown+sidenotes.md | 14 +++++++------- .../mmmfs/framework/text$markdown+sidenotes.md | 7 ++++--- .../historical-approaches/text$markdown+sidenotes.md | 7 ++++--- root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md | 18 +++++++++--------- .../mmmfs/motivation/app-types/text$markdown.md | 4 ++-- .../mmmfs/motivation/text$markdown+sidenotes.md | 18 +++++++++--------- root/articles/mmmfs/references/acm-dl/text$bibtex | 1 + root/articles/mmmfs/references/adobe/text$bibtex | 2 +- root/articles/mmmfs/references/linux-exec/text$bibtex | 1 + root/articles/mmmfs/references/osx-files/text$bibtex | 1 + root/articles/mmmfs/references/renaming/text$bibtex | 1 + root/articles/mmmfs/references/wikipedia/text$bibtex | 1 + .../mmmfs/table-of-contents/text$html+frag.html | 6 +++--- 16 files changed, 51 insertions(+), 44 deletions(-) (limited to 'root') diff --git a/root/articles/mmmfs/ba_log/2019-10-10/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-10/text$markdown.md index 549ea99..010f861 100644 --- a/root/articles/mmmfs/ba_log/2019-10-10/text$markdown.md +++ b/root/articles/mmmfs/ba_log/2019-10-10/text$markdown.md @@ -30,7 +30,7 @@ That means that when the root fileder is rendered, currently 120MB of data have Now that the client can render content within the web browser again, that would be even worse due to the network delay. To solve this, the Fileder implementation now lazy-loads \[[`9632233`][9632233]\]. -When a Fileder is created, it initially knows only its path, but doesn't know which factes or children it contains. +When a Fileder is created, it initially knows only its path, but doesn't know which facets or children it contains. As soon as that data is attempted to be accessed, the fileder loads in the list of its children and facets from the datastore. The facet contents are loaded only when they are actually needed to fulfill a data request or conversion. diff --git a/root/articles/mmmfs/ba_log/2019-10-29/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-29/text$markdown.md index 9656562..4119d21 100644 --- a/root/articles/mmmfs/ba_log/2019-10-29/text$markdown.md +++ b/root/articles/mmmfs/ba_log/2019-10-29/text$markdown.md @@ -1,4 +1,4 @@ -Today i implemented updating/saving content in the server, and bridged the feature to the client. +Today I implemented updating/saving content in the server, and bridged the feature to the client. In the inspector there is now a `save changes` button that (attempts to) save the content on the server's filesystem \[[`4b8d9be`][4b8d9be]\]. diff --git a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md index 70b8df5..27181a8 100644 --- a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md @@ -25,7 +25,7 @@ separately from its parent and context in most cases. This has made the implemen than initially anticipated. ### 6.1.2 pinwall -The pinwall example shows some strenghts of the mmmfs system pretty convincingly. +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. @@ -80,7 +80,7 @@ while others may be intrinsic limitations in the approach taken. 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 conatining multiple images wants to provide custom UI for each image when viewed independently, +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 @@ -94,7 +94,7 @@ Additionally it could be made possible to use this mechanism to locally override 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 reincforcing, +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 @@ -109,7 +109,7 @@ This weakness represents a failure to (fully) implement the quality of a "Living *Ink and Switch*. 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 particularily relevant +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. @@ -148,7 +148,7 @@ viewable HTML markup, but it is hardly possible to propagate changes to the view This particular instance of the problem might be solvable using a Rich-Text editor, but the general problem worsens when the conversion path becomes more complex: If the markdown source was fetched via HTTP from a remote URL (e.g. if the facet's type was `URL -> text/markdown`), it is not possible to edit the content at all, since the only data owned by -the system is the URL string itself, which is not part of the viewable representation. Similarily, when viewing output +the system is the URL string itself, which is not part of the viewable representation. Similarly, when viewing output that is generated by code (e.g. `text/moonscript -> mmm/dom`), the code itself is not visible to the user, and if the user wishes to change parts of the representation, the system is unable to relate these changes to elements of the code or assist the user in doing so. diff --git a/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md b/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md index d32b0db..0a82a51 100644 --- a/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md +++ b/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md @@ -12,22 +12,22 @@ This makes it suitable for denoting formatted-text titles and other small string 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 mmm. +`` and ``, which respectively embed and link to other content native to mmmfs. -### 5.1.2 scientific publishing +### 5.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, since it does not support interaction.

-Scientific publishing is notoriously complex, involving not only the transclusion of diagrams +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 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 scientific document; +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, and then shown again with full details at the end of the document. @@ -44,9 +44,9 @@ 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 spacially so that they can be viewed +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 organise references to articles, +Such a pinwall could serve for example to organize references to articles, to collect visual inspiration for a moodboard etc. As a collection, the Pinwall is primarily mapped to a Fileder in the system. @@ -75,7 +75,7 @@ advanced (and rewound) one by one using keypresses. The implementation of this is rather straightforward as well. The slideshow as a whole becomes a fileder with a script that generates a designated viewport rectangle, as well as a control interface with keys for advancing the active slide. -It also allows putting the browser into fullscreen mode to maximise screenspace and remove visual elements +It also allows putting the browser into fullscreen mode to maximize screen space and remove visual elements of the website that may distract from the presentation, and register an event handler for keyboard accelerators for moving through the presentation. diff --git a/root/articles/mmmfs/framework/text$markdown+sidenotes.md b/root/articles/mmmfs/framework/text$markdown+sidenotes.md index 81acb02..0df28c4 100644 --- a/root/articles/mmmfs/framework/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/framework/text$markdown+sidenotes.md @@ -17,7 +17,7 @@ end-user programming > Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes > it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer. > Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a @@ -52,7 +53,7 @@ directly to the concept of *Embodiment* described by Ink & Switch. 3.3 content transclusion ------------------------ -The strengths of modular architectures should similarily extend also into the way the system will be used by users. +The strengths of modular architectures should similarly extend also into the way the system will be used by users. If users are to store their information and customized behaviour in such an architecture, then powerful tools need to be present in order to assemble more complex solutions out of such parts. Therefore static content should be able to be linked to (as envisioned for the *Memex*, see above), but also to be *transcluded*, to facilitate the creation of flexible data formats and interactions, such that e.g. a slideshow slide can include content in a variety other formats (such as images and text) from anywhere else in the system. Behaviours also should be -able to be transcluded and reused to facilitate the creation of ad-hoc sytems and applets based on user needs. For +able to be transcluded and reused to facilitate the creation of ad-hoc systems and applets based on user needs. For example a user-created todo list should be able to take advantage of a sketching tool the user already has access to. By forming the immediately user-visible layer of the system out of the same abstractions that the deeper levels of the diff --git a/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md b/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md index 812d751..c022021 100644 --- a/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md @@ -8,9 +8,10 @@ other systems at the time, as well as the systems we use currently, is that the directly known to the system. In a retrospective analysis of the Xerox Star's impact on the computer -industry, the desktop metaphor is described as +industry, the desktop metaphor is described as follows: + > In a Desktop metaphor system, users deal mainly with data files, oblivious to the existence of programs. > They do not "invoke a text editor", they "open a document". > The system knows the type of each file and notifies the relevant application program when one is opened. @@ -28,7 +29,7 @@ surely been lost. Another design detail of the Star system is the concept of "properties" that are stored for "objects" throughout the system (the objects being anything from files to characters or paragraphs). These typed pieces of information are labelled with a name and persistently stored, providing a mechanism to store metadata such as user preference for -ordering or the defaut view mode of a folder for example. +ordering or the default view mode of a folder for example. @@ -47,7 +48,7 @@ true or inspired .... One of the most innovative elements of Bush's predictions is the idea of technologically cross-referenced and connected information, which would later be known and created as *hypertext*. While hypertext powers the majority of today's internet, many of the advantages that Bush imagined have not carried over into the personal use of computers. -There are very few tools for creating personal, highly-interconnected knowledgebases, even though it is technologically +There are very few tools for creating personal, highly-interconnected knowledge bases, even though it is technologically feasible and a proven concept (exemplified for example by the massively successful online encyclopedia *Wikipedia*). diff --git a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md index 28030d7..883af51 100644 --- a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md @@ -1,4 +1,4 @@ -# 4. mmmfs +# 4. system description `mmmfs` is a newly developed personal data storage and processing system. It was developed first as a tool for generating static websites, but has been extended with live interaction and introspection, as well as embedded @@ -7,12 +7,12 @@ editing capabilities as part of this work. mmmfs has been designed with a focus on data ownership for users. One of the main driving ideas is to unlock data from external data silos and file formats by making data available uniformly across different storage systems and formats. Secondly, computation and interactive elements are also integrated in the paradigm, so that mmmfs can be -seemlessly extended and molded to the users needs. +seamlessly extended and molded to the users needs. The abstraction of data types is accomplished using two major components, the *Type System and Coercion Engine* and the *Fileder Unified Data Model* for unified data storage and access. -## 4.1 the fileder unified data model +## 4.1 data storage model The Fileder Model is the underlying unified data storage model. Like many data storage models it is based fundamentally on the concept of a hierarchical tree-structure. @@ -59,7 +59,7 @@ In mmmfs, the example above might look like this instead: Superficially, this may look quite similar: there is still only two types of nodes (referred to as *fileders* and *facets*), and again one of them, the *fileders* are used only to hierarchically organize *facets*. Unlike *files*, -*factes* don't only store a freeform *name*, there is also a dedicated *type* field associated with every *facet*, that +*facets* don't only store a freeform *name*, there is also a dedicated *type* field associated with every *facet*, that is explicitly designed to be understood and used by the system. Despite the similarities, the semantics of this system are very different: In mainstream filesystems, each *file* stands @@ -77,7 +77,7 @@ Semantically a *fileder*, like a *directory*, also encompasses all the other *fi (recursively). Since *fileders* are the primary unit of data to be operated upon, *fileder* nesting emerges as a natural way of structuring complex data, both for access by the system and its components, as well as the user themself. -## 4.2 the type system & coercion engine +## 4.2 type system and coercion engine As mentioned above, *facets* store data alongside its *type*, and when a component of the system requires data from a *fileder*, it has to specify the *expected type* (or a list of these) that it requires the data to be in. The system then attempts to coerce one of the existing facets into the *expected type*, if possible. This process can involve many @@ -95,7 +95,7 @@ Here are some common MIME-types that are also used in mmmfs: - `image/png` - `image/jpeg` -While these types allow some amount of specifity, they fall short of describing their content especially in cases where +While these types allow some amount of specificity, they fall short of describing their content especially in cases where formats overlap: Source code for example is often distributed in `.tar.gz` archive files (directory-trees that are first bundled into an `application/x-tar` archive, and then compressed into an `application/gzip` archive). Using either of these two types is respectively incorrect or insufficient information to properly treat and extract the contained data. @@ -148,7 +148,7 @@ they return depend on the input type, as is required often when nested types are } This *convert* accepts an `application/gzip` *type* wrapping any other *type*, and captures that nested type in a -pattern group. It then uses the substituion syntax to specify that nested type as the output of the conversion. +pattern group. It then uses the substitution syntax to specify that nested type as the output of the conversion. For an input *type* of `application/gzip -> image/png` this *convert* would therefore generate the type `image/png`. This last example further demonstrates the flexibility of this approach: @@ -166,11 +166,11 @@ In addition to the attributes shown above, every *convert* is also rated with a roughly estimate both the cost (in terms of computing power) of the conversion, as well as the accuracy or immediacy of the conversion. For example, resizing an image to a lower size should have a high cost, because the process is computationally expensive, but also because a smaller image represents the original image to a lesser degree. -Similarily, an URL to a piece of content is a less immediate representation than the content itself, so the cost of a +Similarly, an URL to a piece of content is a less immediate representation than the content itself, so the cost of a *convert* that simply generates the URL to a piece of data should be high even if the process is very cheap to compute. Cost is defined in this way to make sure that the result of a type-coercion operation reflects the content that was -present as accurately as possible. It is also important to prevent some nonsensical results from occuring, such as +present as accurately as possible. It is also important to prevent some nonsensical results from occurring, such as displaying a link to content instead of the content itself because the link is cheaper to create than completely converting the content does. diff --git a/root/articles/mmmfs/motivation/app-types/text$markdown.md b/root/articles/mmmfs/motivation/app-types/text$markdown.md index aac79d7..aedef1c 100644 --- a/root/articles/mmmfs/motivation/app-types/text$markdown.md +++ b/root/articles/mmmfs/motivation/app-types/text$markdown.md @@ -1,3 +1,3 @@ While there can be a distinction between *Native Applications* and *Web Applications* or *Cloud Services*, the following -arguments apply to all different technicalal implementations of this same concept. The problems associated -specifically with Web- and Cloud-based application models will be discussed separately below. +arguments apply to all different technical implementations of this same concept. The problems associated specifically +with Web- and Cloud-based application models will be discussed separately below. diff --git a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md index 9bfdea5..e2e6550 100644 --- a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md @@ -4,7 +4,7 @@ ------------------------------ The majority of users interact with modern computing systems in the form of smartphones, laptops or desktop PCs, -using the mainstream operating systems Apple iOS and Mac OS X, Microsoft Windows or Android. +using the mainstream operating systems Apple iOS and Mac OS X, Microsoft Windows or Android. All of these operating systems share the concept of *Applications* (or *Apps*) as one of the core pieces of their @@ -12,8 +12,8 @@ interaction model. Functionality and capabilities of the digital devices are bun as applications. This focus on applications as the primary unit of systems can be seen as the root cause of multiple problems. For one, since applications are produced by private companies on the software market, -developers compete on features integrated into their applications. To stay relevant, monlithic software or software -suites tend to accrete features rather then modularise and delegate to other software. This makes many software packages more complex and unintuitive than they need to be, and also cripples interoperability between applications and data formats. @@ -52,9 +52,9 @@ other than through a standardized set of interactions (e.g. selecting a file via video from a webcam, opening another website). Cloud software, as well as subscription-model software with online-verification mechanisms, are additionally subject -to license changes, updates modifiying, restricting or simply removing past functionality etc. Additionally, many cloud +to license changes, updates modifying, restricting or simply removing past functionality etc. Additionally, many cloud software solutions and ecosystems store the users' data in the cloud, often across national borders, where legal and -privacy concerns are intransparently handled by the companies. If a company, for any reason, is unable or unwanting to +privacy concerns are intransparently handled by the companies. If a company, for any reason, is unable or unwilling to continue servicing a customer, the users data may be irrecoverably lost (or access prevented). This can have serious consequences, especially for professional users, for whom an inability to access their tools or their cloud-stored data can pose an existential threat. @@ -65,11 +65,11 @@ whom an inability to access their tools or their cloud-stored data can pose an e Cragg coins the term "inert data" for the data created and left behind by apps and applications in the computing model that is currently prevalent: Most data today is either intrinsically linked to one specific application, that controls and limits access to the actual information, -or, even worse, stored in the cloud where users have no direct access at all. In the latter case users depend soley on +or, even worse, stored in the cloud where users have no direct access at all. In the latter case users depend solely on online tools that require a stable network connection and a modern browser and could be modified, removed, or otherwise negatively impacted at any moment. -Aside from being inaccesible to users, the resulting complex proprietary formats are also opaque and useless to other +Aside from being inaccessible to users, the resulting complex proprietary formats are also opaque and useless to other applications and the operating system, which often is a huge missed opportunity: The .docx format for example, commonly used for storing mostly textual data enriched with images and on occasion videos, is in fact a type of archive that can contain many virtual files internally, such as the various media files contained @@ -110,7 +110,7 @@ To avoid facing this dilemma, a more sensible system could leave the task of pos different types to one software component, while multiple different software components could be responsible for editing the individual pieces of content, so that the most appropriate one can be chosen for each element. While creating the technological interface between these components is certainly a challenge, the resulting system would greatly benefit -from the exponentially-growing capabilties resulting from the modular reuse of components across many contexts: A rich +from the exponentially-growing capabilities resulting from the modular reuse of components across many contexts: A rich text editor component could be used for example not just in a mixed media collection as proposed above, but also for an email editor or the input fields in a browser. @@ -121,7 +121,7 @@ deeply understanding the software they use and the data they own, from customizi interactions, and from properly owning, contextualising and connecting their data. Interestingly, these deficits do not appear throughout the history of today's computing systems, but are based in rather -recent developments in the field. In fact the most influental systems in the past aspired to the polar opposites, as i +recent developments in the field. In fact the most influential systems in the past aspired to the polar opposites, as I will show in the next section. On the other hand, the development of the technical framework for this thesis has posed greater challenges. -In particular, the implementation of the reference and sidenote systems are brittle and uninspiring. - +While the reference and sidenote systems integrated well with the rest of the system, some features like automated +table-of-contents and section numbering were less obvious to tackle and finally completed manually. 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 history effectively. -Another issue is that the system is currently based on the presumption that content can and should be interpreted -separately from its parent and context in most cases. This has made the implementation of sidenotes less idiomatic -than initially anticipated. +mechanisms to re-capture information spread throughout the resulting hierarchy effectively. ### 6.1.2 pinwall The pinwall example shows some strengths of the mmmfs system pretty convincingly. @@ -73,8 +69,8 @@ more general `mmm/dom` type-interface, allowing for a greater variety of types o ## 6.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. -Some of these have been anticipated for some time and concrete research directions for solutions are apparent, -while others may be intrinsic limitations in the approach taken. +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 In the current system, there is only a single, global set of *converts* that can be potentially applied to facets diff --git a/root/articles/mmmfs/framework/text$markdown+sidenotes.md b/root/articles/mmmfs/framework/text$markdown+sidenotes.md index 0df28c4..e85bf42 100644 --- a/root/articles/mmmfs/framework/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/framework/text$markdown+sidenotes.md @@ -1,8 +1,10 @@ # 3. evaluation framework -In the following section, I will collect approaches and reviews of different end-user software systems from current -literature, as well as derive and present my own requirements and guiding principles for the development of a new -system. +In this section, I will collect approaches and reviews of different end-user software systems from current literature, +as well as derive and present my own requirements and guiding principles for the development of a new system. + +Firstly, I will take a look at a framework for evaluating end-user computing systems from literature, before presenting +three concrete design principles and components for a new system. 3.1 qualities of successful end-user computing ---------------------------------------------- diff --git a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md index 883af51..2b2263e 100644 --- a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md @@ -1,16 +1,18 @@ # 4. system description -`mmmfs` is a newly developed personal data storage and processing system. It was developed first as a tool for -generating static websites, but has been extended with live interaction and introspection, as well as embedded -editing capabilities as part of this work. +Alongside this thesis a new end-user computing system has been developed together with the framework presented above. +The system, `mmmfs`, is a personal data storage and processing system that was initially developed as a tool for +generating static websites, but has now been extended with capabilities for live interaction and introspection, as well +as embedded editing, as part of this work. mmmfs has been designed with a focus on data ownership for users. One of the main driving ideas is to unlock data from external data silos and file formats by making data available uniformly across different storage systems and -formats. Secondly, computation and interactive elements are also integrated in the paradigm, so that mmmfs can be -seamlessly extended and molded to the users needs. +formats. Secondly, computation and interactive elements are also integrated in this paradigm, so that mmmfs can be +seamlessly extended and molded to the user's needs. The abstraction of data types is accomplished using two major components, the *Type System and Coercion Engine* and -the *Fileder Unified Data Model* for unified data storage and access. +the *Fileder Unified Data Model* for unified data storage and access. In the next sections the design and implementation +of these two components will be described in detail. ## 4.1 data storage model The Fileder Model is the underlying unified data storage model. diff --git a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md index e2e6550..9433e74 100644 --- a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md +++ b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md @@ -1,5 +1,9 @@ # 1. motivation +The project that this thesis accompanies was created out of a frustration with the computing systems that are currently +popular and widely available to end-users. The following sections document and exemplify the perceived shortcomings that +these systems exhibit, as attributed to specific concepts or paradigms that the systems seem to be designed around. + 1.1 application-centric design ------------------------------ @@ -9,7 +13,8 @@ using the mainstream operating systems Apple iOS and Mac OS X, Microso All of these operating systems share the concept of *Applications* (or *Apps*) as one of the core pieces of their interaction model. Functionality and capabilities of the digital devices are bundled in, marketed, sold and distributed -as applications. This focus on applications as the primary unit of systems can be seen as the root cause of multiple problems. +as applications. This focus on applications as the primary unit of systems can be seen as the root cause of multiple +problems. For one, since applications are produced by private companies on the software market, developers compete on features integrated into their applications. To stay relevant, monolithic software or software diff --git a/root/articles/mmmfs/table-of-contents/text$html+frag.html b/root/articles/mmmfs/table-of-contents/text$html+frag.html index 10004f0..911d8b8 100644 --- a/root/articles/mmmfs/table-of-contents/text$html+frag.html +++ b/root/articles/mmmfs/table-of-contents/text$html+frag.html @@ -34,6 +34,7 @@

abstract
table of contents
overview
1. motivation

1.1 application-centric design

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.

Oscilloscope Music and Games with Pure Data

JavaScript

JavaScript

Statement of Originality

Empowered End-User Computing

Statement of Originality

statement of originality

table of contents