Commit dc7ee6dc261d5c3351552ed092c9d7ed66f163cc - mmm

more write- and referencing s-ol 2 years ago

8 changed file(s) with 90 addition(s) and 39 deletion(s). Raw diff Collapse all Expand all

-4

root/articles/mmmfs/evaluation/text$markdown+sidenotes.md less more

92	92	Additionally it could be made possible to use this mechanism to locally override converts inherited from
93	93	further up in the tree, for example to specialize types based on their context in the system.
94	94
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.
99	98
100	99	### code outside of the system
101	100	At the moment, a large part of the mmmfs codebase is still separate from the content, and developed outside of mmmfs

+59

-32

root/articles/mmmfs/framework/text$markdown+sidenotes.md less more

1	1	====================
2	2
3	3	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	----------
5	30
6	31	The UNIX Philosophy <mmm-link path="../references/unix"></mmm-link> describes the software design paradigm
7	32	pioneered in the creation of the Unix operating system at the AT&T Bell Labs research center in the 1960s. The
8	33	concepts are considered quite influental and are still notably applied in the Linux community. Many attempts at
9	34	summaries exist, but the following includes the pieces that are especially relevant even today:
10	35
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.
16	41
17	42	This approach has multiple benefits with regard to end-user programmability: Assembling the system out of simple,
18	43	modular pieces means that for any given task a user may want to implement, it is very likely that preexisting parts
19	44	of the system can help the user realize a solution. Wherever such a preexisting part exists, it pays off designing it
20	45	in such a way that it is easy to integrate for the user later. Assembling the system as a collection of modular,
21	46	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.
23	48
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.
30	51
31		The system should enable the quick creation of ad-hoc software.
	52	content transclusion
	53	--------------------
32	54
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.
37	65
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	--------------------
39	79
40	80	In order to provide users full access to their information as well as the computational infrastructure,
41	81	users need to be able to finely customize and reorganize the smallest pieces to suit their own purposes,

48	88	conventional programming languages are used for the time being.
49	89	Confidence is placed in the fact that eventually more user-friendly languages will be available and,
50	90	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.

+11

-1

root/articles/mmmfs/motivation/text$markdown+sidenotes.md less more

50	50	cloud computing
51	51	---------------
52	52
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:
54	54	In most cases, they are only accessible or functional in the presence of a stable internet connection,
55	55	and they have very limited access to the resources of the physical computer they are running on.
56	56	For example, they usually cannot interact directly with the file system, hardware peripherals or other applications,

116	116	different types to one software component, while multiple different software components can be responsible for editing
117	117	the individual pieces of content, so that the most appropriate one can be chosen for each element.
118	118
	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
119	129	<!--
120	130	Chiusano blames these issues on the metaphor of the machine, and likens apps and applications to appliances.
121	131	According to him, what should really be provided are tools:

-1

root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon less more

6	6	import article, h1, h2, h3, section, p, div, a, sup, ol, li, span, code, pre, br from html
7	7	import moon from (require 'mmm.highlighting').languages
8	8
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' }
10	10	append = (a) -> table.insert _this, a
11	11
12	12	footnote, getnotes = do

-0

root/articles/mmmfs/references/$order less more

14	14	acm-dl
15	15	aspect-ratios
16	16	alternatives-to-trees
	17	transclusion

+10

-0

root/articles/mmmfs/references/transclusion/text$bibtex less more

	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	}

-1

root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon less more

6	6	import article, h1, h2, h3, section, p, div, a, sup, ol, li, span, code, pre, br from html
7	7	import moon from (require 'mmm.highlighting').languages
8	8
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' }
10	10	append = (a) -> table.insert _this, a
11	11
12	12	footnote, getnotes = do

-0

scss/_content.scss less more

103	103	background: $gray-bright;
104	104	border-color: $gray-neutral;
105	105	}
	106
	107	.well-warning {
	108	border-color: $gray-fail;
	109	}
106	110	}