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.
|