git.s-ol.nu mmm / dc7ee6d
more write- and referencing s-ol 1 year, 11 months ago
8 changed file(s) with 90 addition(s) and 39 deletion(s). Raw diff Collapse all Expand all
9292 Additionally it could be made possible to use this mechanism to locally override *converts* inherited from
9393 further up in the tree, for example to specialize types based on their context in the system.
9494
95 The biggest downside to this approach would be that it presents another pressure factor for,
96 while also reincforcing, the hierarchical organization of data,
97 thereby exacerbating the limits of hierarchical structures.<div class="sidenote">see also
98 <mmm-embed raw path="../references/alternatives-to-trees"></mmm-embed></div>
95 <div class="sidenote">see also <mmm-embed raw path="../references/alternatives-to-trees"></mmm-embed>
96 </div>The biggest downside to this approach would be that it presents another pressure factor for, while also
97 reincforcing, the hierarchical organization of data, thereby exacerbating the limits of hierarchical structures.
9998
10099 ### code outside of the system
101100 At the moment, a large part of the mmmfs codebase is still separate from the content, and developed outside of mmmfs
11 ====================
22
33 In the following section, I will collect approaches and reviews of different end-user software systems from current
4 literature, as well as derive and present my own requirements and guiding principles for the development of a new system.
4 literature, as well as derive and present my own requirements and guiding principles for the development of a new
5 system.
6
7 qualities
8 ---------
9
10 *Ink and Switch* suggest three qualities for tools striving to support
11 end-user programming<mmm-link path="../references/inkandswitch"></mmm-link>:
12
13 - *Embodiment*, i.e. reifying central concepts of the programming model as more concrete, tangible objects
14 in the digital space (for example through visual representation),
15 in order to reduce cognitive load on the user.
16 - *Living System*, by which they seem to describe the malleability of a system or environment,
17 and in particular the ability to make changes at different levels of depth in the system with
18 very short feedback loops and a feeling of direct experience.
19 - *In-place toolchain*, denoting the availability of tools to customize and author the experience,
20 as well as a certain accesibility of these tools, granted by a conceptual affinity between the
21 use of the tools and general 'passive' use of containing system at large.
22
23 These serve as guiding principles for the design and evaluation of computer systems for end-users, but are by nature
24 very abstract. The following properties are therefore derived as more concrete proposals based on some more specific
25 constraints: namely the construction of a system for end-users to keep, structure and display personal information and
26 thoughts in.
27
28 modularity
29 ----------
530
631 The *UNIX Philosophy* <mmm-link path="../references/unix"></mmm-link> describes the software design paradigm
732 pioneered in the creation of the Unix operating system at the AT&T Bell Labs research center in the 1960s. The
833 concepts are considered quite influental and are still notably applied in the Linux community. Many attempts at
934 summaries exist, but the following includes the pieces that are especially relevant even today:
1035
11 > Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well.
12 > Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be
13 > written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs
14 > than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs,
15 > become general and useful tools.
36 > Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes
37 > it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer.
38 > Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a
39 > system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite
40 > trivial things in isolation, but, combined with other programs, become general and useful tools.
1641
1742 This approach has multiple benefits with regard to end-user programmability: Assembling the system out of simple,
1843 modular pieces means that for any given task a user may want to implement, it is very likely that preexisting parts
1944 of the system can help the user realize a solution. Wherever such a preexisting part exists, it pays off designing it
2045 in such a way that it is easy to integrate for the user later. Assembling the system as a collection of modular,
2146 interacting pieces also enables future growth and customization, since pieces may be swapped out with customized or
22 alternate software at any time.
47 alternate software at any time.
2348
24 Based on this, a modern data storage and processing ecosystem should enable transclusion of both content and behaviours
25 between contexts.
26 Content should be able to be transcluded and referenced to facilitate the creation of flexible data formats and interactions,
27 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.
28 Behaviours should be able to be transcluded and reused to facilitate the creation of ad-hoc sytems and applets based on user needs.
29 For example a user-created todo list should be able to take advantage of a sketching tool the user already has access to.
49 Settling on a specific modular design model, and reifying other components of a system in terms of it also corresponds
50 directly to the concept of *Embodiment* described by Ink & Switch.
3051
31 The system should enable the quick creation of ad-hoc software.
52 content transclusion
53 --------------------
3254
33 While there are drawbacks to cloud-storage of data (as outlined above), the utility of distributed systems is acknowledged,
34 and the system should therefore be able to include content and behaviours via the network.
35 This ability should be integrated deeply into the system,
36 so that data can be treated independently of its origin and storage conditions, with as little caveats as possible.
55 The strengths of modular architectures should similarily also extend into the way the system will be used by users.
56 If users are to store their information and customized behaviour in such an architecture, then powerful tools need to be
57 present in order to assemble more complex solutions out of such parts. Therefore static content should be able to be
58 linked to (as envisioned for the *Memex*, see above), but also to be <span class="sidenote">The term <i>transclusion</i>
59 refers to the concept of including content from a separate document, possibly stored remotely, by reference rather than
60 by duplication. See also <mmm-embed raw path="../references/transclusion"></mmm-embed></span>*transcluded*,
61 to facilitate the creation of flexible data formats and interactions, such that e.g. a slideshow slide can include
62 content in a variety other formats (such as images and text) from anywhere else in the system. Behaviours also should be
63 able to be transcluded and reused to facilitate the creation of ad-hoc sytems and applets based on user needs. For
64 example a user-created todo list should be able to take advantage of a sketching tool the user already has access to.
3765
38 The system needs to be browsable and understandable by users.
66 By forming the immediately user-visible layer of the system out of the same abstractions that the deeper levels of the
67 system are made of, the sense of a *Living System* is also improved: skills that are learned at one (lower) level of the
68 system carry on into further interaction with the system on deeper levels, as does progress in understanding the
69 system's mechanisms.
70
71 While there are drawbacks to cloud-storage of data (as outlined above), the utility of distributed systems is
72 acknowledged, and the system should therefore be able to include content and behaviours via the network.
73 This ability should be integrated deeply into the system, so that data can be treated independently of its origin and
74 storage conditions, with as little caveats as possible. In particular, the interactions of remote data access and
75 content transclusion should be paid attention to and taken into consideration for a system's design.
76
77 end-user programming
78 --------------------
3979
4080 In order to provide users full access to their information as well as the computational infrastructure,
4181 users need to be able to finely customize and reorganize the smallest pieces to suit their own purposes,
4888 conventional programming languages are used for the time being.
4989 Confidence is placed in the fact that eventually more user-friendly languages will be available and,
5090 given the goal of modularity, should be implementable in a straightforward fashion.
51
52 *Ink and Switch* suggest three qualities for tools striving to support
53 end-user programming<mmm-link path="../references/inkandswitch"></mmm-link>:
54
55 - "Embodiment", i.e. reifying central concepts of the programming model as more concrete, tangible objects
56 in the digital space (for example through visual representation),
57 in order to reduce cognitive load on the user.
58 - "Living System", by which they seem to describe the malleability of a system or environment,
59 and in particular the ability to make changes at different levels of depth in the system with
60 very short feedback loops and a feeling of direct experience.
61 - "In-place toolchain", denoting the availability of tools to customize and author the experience,
62 as well as a certain accesibility of these tools, granted by a conceptual affinity between the
63 use of the tools and general 'passive' use of containing system at large.
5050 cloud computing
5151 ---------------
5252
53 *Web Apps* often offer similar functionality to other *Applications*, but are subject to additional limitations:
53 *Web Apps* often offer similar functionality to other applications, but are subject to additional limitations:
5454 In most cases, they are only accessible or functional in the presence of a stable internet connection,
5555 and they have very limited access to the resources of the physical computer they are running on.
5656 For example, they usually cannot interact directly with the file system, hardware peripherals or other applications,
116116 different types to one software component, while multiple different software components can be responsible for editing
117117 the individual pieces of content, so that the most appropriate one can be chosen for each element.
118118
119 <div style="height: 2rem;"></div>
120
121 To summarize, for various reasons, the metaphors and interfaces of computing interfaces today prevent users from deeply
122 understanding the software they use and the data they own, from customizing and improving their experience and
123 interactions, and from properly owning, contextualising and connecting their data.
124
125 Interestingly, these deficits do not appear throughout the history of todays computing systems, but are based in rather
126 recent developments in the field. In fact the most influental systems in the past aspired to the polar opposites, as i
127 will show in the next section.
128
119129 <!--
120130 Chiusano blames these issues on the metaphor of the *machine*, and likens apps and applications to appliances.
121131 According to him, what should really be provided are *tools*:
66 import article, h1, h2, h3, section, p, div, a, sup, ol, li, span, code, pre, br from html
77 import moon from (require 'mmm.highlighting').languages
88
9 article with _this = class: 'sidenote-container', style: { 'max-width': '640px' }
9 article with _this = class: 'sidenote-container', style: { 'max-width': '640px', 'text-align': 'justify' }
1010 append = (a) -> table.insert _this, a
1111
1212 footnote, getnotes = do
1414 acm-dl
1515 aspect-ratios
1616 alternatives-to-trees
17 transclusion
0 @article{article,
1 author = {Kolbitsch, Josef and Maurer, Hermann},
2 year = {2006},
3 month = {06},
4 pages = {161-173},
5 title = {Transclusions in an HTML-Based Environment},
6 volume = {14},
7 journal = {CIT},
8 doi = {10.2498/cit.2006.02.07},
9 }
66 import article, h1, h2, h3, section, p, div, a, sup, ol, li, span, code, pre, br from html
77 import moon from (require 'mmm.highlighting').languages
88
9 article with _this = class: 'sidenote-container', style: { 'max-width': '640px' }
9 article with _this = class: 'sidenote-container', style: { 'max-width': '640px', 'text-align': 'justify' }
1010 append = (a) -> table.insert _this, a
1111
1212 footnote, getnotes = do
103103 background: $gray-bright;
104104 border-color: $gray-neutral;
105105 }
106
107 .well-warning {
108 border-color: $gray-fail;
109 }
106110 }