Considering the Fountain Pen - On Borrowing versus Re-thinking
The monad is an irreducible object that remains inert until called upon for assembly. This is most easily compared to a database which themselves remain inert until an inquiry calls for parts of the database. With monads (e.g. colors, letters, scientific papers, programs, etc), a call for possession means an assemblage is created. That assemblage will exist as long as the possessing action has the strength to maintain it. An assemblage will call upon other and dispense monads over time; this accounts for how assemblages change. Once that assemblage begins to fail tests of strength, its elements, its monads are sent back into the ether.
The act of design is an attempt to create a tangible, manifest idea using monads. For example, a designer wants to create a situational awareness application for a geographic area. In order to design this application, the designer must call upon monads like geotagged data, local entities, electrical grid information, and various other monads. This assemblage begins much like the database in that designers assemble a number of monads into what resembles their design. The monadology, or product, is then sent out as a monad in and of itself. At times, this act of sending a product into the ether is bundled with advertising or notations that a particular monad is worthy of attention.
The success of a product is dependent on its ability to overcome trials of strength. A trial of strength in this case is the ability an assemblage to maintain cohesion - this includes being called upon at all (or used). Not all failed trials of strength are ends to that assemblage entirely. Products, especially those in information technology, are able to be augmented, re-assembled, and re-distributed. Patches, competitor alternatives, and alternate use scenarios are ways through which this monad is reassembled and redistributed over time. As such, an assemblage could fail a trial of strength against similar assemblages (e.g. Open Office over Microsoft Office).
The Study of Design
Typically when we discuss design, we often call upon the assemblage (finished product) and not the assembly (the design process that product followed). Assembly talk is for designers or assemblers and this typically follows discussions into individual processes of specific monads, not the entirety of the act of assembling. This duality also manifests in interesting ways. For example, designers themselves often test their assemblage on users. They do not test the process of assembly, nor do they often make record it. The gap between the act of assembly and the assemblage itself has lead to undefinable, unmeasurable issues in design as the act is often responsible for more than just the assemblage.
In order to better consider the way in which products are assembled, how they change (or are reassembled), and where they fit once called upon (by other assemblages like users, nonhuman aggregators, or other types of use), I believe it is necessary to re-think how we test designs both in situ and the timing of that testing throughout the act of assembly.
Many of the ways created to study groups of users were adopted or (by some accounts) stolen from the social science. Along with that adoption came the baggage that had initially forced the creation of a new field in the first place. I believe that a method created independent of traditional methodologies in the social sciences would allow designers to gain more useful insights into the nature of their products.
Much of the above discussion was thinking through Leibniz’s Monads with additional input from Gabriel Tarde in the late 1800s, and application to present ideas by Bruno Latour. I believe that a product cannot truly be tested as a whole. Instead, the parts that make up the whole should be the focus of testing. While traditionally certain monads are called upon when they manifest in user testing, this is often done so through the gaze of the user as it manifests throughout testing. By re-thinking that mode of testing, designers could begin to understand particular elements of their assemblage outside of it manifesting directly through use.
For example, I have begun to purchase fountain pens as I have begun to disconnect myself from a computer when I write. One thing that I have had to come to understand is that a pen consists of:
- A nib,
- The feed,
- A section,
- A converter,
- A cap
- A barrel
The nib is where the ink comes out. The feed is what controls the level of ink coming out of the nub, the converter is where the ink is stored, the cap protects the nib from damage and drying while the barrel protects everything else from damage.
As I use this product, some aspect of it will break down. This is a failure of design (though perhaps not by the designers themselves, but the manufacturers of the products that go into a fountain pen). Should this pen have been a digital manifestation that I (or someone) was using, that pen would fail a test of strength and probably be uninstalled, deleted, or simply abandoned for some new assemblage.
One of the unmeasurable consequences of assemblage based testing is that everyone involved, from assembly to use, tends to think in terms of the whole. Yet, by breaking a product down we can consider what aspect of a pen are not functioning correctly. In this case, the converter has gotten backed up due to a dried pool that is blocking flow through the feed. This is actually my fault as a user.
How to Do?
So how does one achieve this examination of an assemblage from a non-assembled aspect? I believe that it is most easily achieved by pursuing the the most equivalent method to tracing monads - an augmented social network analysis.
In social network analysis, before the performance of tests like centrality, homophily, propinquity, or betweenness, a map of interactions is created. Through careful observation, a map of interaction between humans (assemblages of a sort) and their nonhuman equivalents (monads or assemblages of a non-human variety) will allow designers to view what aspects of their product are being called upon. Through this map, it will become possible to see the social life of an assemblage from the perspective of its individual aspects - physical and non-physical (procedural rhetoric, back-end design, etc).
Over time, those interactions will indeed form central nodes or those aspects of a product that are called upon the most. For example, a social network through the use of a pen being used to write would resemble something like:
- Intent to write >
- Fingers to grip >
- Nib to Paper >
- Reservoir to Feed >
- Feed to Nib >
- Nib to Paper >
- Fingers to Nib >
- Nib to Symbols.
This relationship would continue as the act itself continued. Time sequences will bound a particular series of interactions. The disruption of nib to symbols would be indicative of a possible problem area. For example, a small set of problems could be: users thinking about symbols, users thinking about the product, users thinking about the paper, users thinking about the paper because of the product.
In all three cases, additional uses for the pen could be observed. For example, during thoughts about the symbols, the pen may be deployed in different ways. This could be putting cap to lips to think. What happens here is an additional way to consider the design of the pen.
The observation of monads allows us to consider each addition of a monad or each call for possession (the pen as a whole becoming part of a new monadology (the act of writing, in this case)). By cataloging these aspects of a design and the manner through which they are connected throughout a given contextual deployment, designers can observe every aspect of their product be called upon.
This is all achieved without borrowing methodologies. It is true that the method SNA is being referred to here. SNA has baggage in and of itself. However, we are not borrowing the method insomuch as being inspired by the act of observing interactions and associations within a given space. The mention of SNA is little more than short-hand and may be dispensed with altogether.
Over the next few weeks, I will be deploying this method in order to consider two different assemblages with the same intent - to play a game. To examine the manner through which monads are called upon when assemblages differ is the goal. In this way, I will test the viability of what is outlined above.