Commit 483d9df4 authored by colmoneill's avatar colmoneill
Browse files

longform reorganisation + modifs to text up to now

parent 1be3b638
Title: Dissertation abstract
Title: Dissertation introduction
Date: 2017/01/01
# Abstract :
The move away from manual crafts towards on-screen counterparts has been ongoing since the first generations of software, in the late 1940s. It is a regular phenomenon in this day and age. Computer and software technologies promise —potential— for accessibility, flexibility, scale and speed of innumerable tasks. Many types of software are available for ranges of jobs, from every day actions to very complex and specific professional needs. This study first presents an understanding of what *craft* means today, now that different professions —say electrical circuit designers and photo editors— use very similar utilities. We look at how the practices and cultures that stem from manual crafts have been affected by their transformations to work within an operating system. It becomes clear that some labours have improved, while others have only —at best— been accelerated by the morphing. Therefor this study puts forward that a confusion between efficiency and efficacy when transforming a craft into a computer program can put severe weight on the origins and traditions of that field, and ultimately make the tool feel hermetic. <!--(tentatively answering the question relative to why it is important that tools and practice transfer culture and knowledge)--> This observation drives the inquiry toward the user and the (re-)learning —curve. What is the users position in the new scheme of actions that is software? Is s/he supposed to know all of the reasoning's and practices or is one to accept that *this is the order of things* without any context? Then, we note that the workplace has also been shifted, first out of physical tools, onto personal computers, and now again onto ‘the cloud’. What is the reasoning behind this third step? Is it necessary? Who is this helping, and what extra barriers does it place between practice and field knowledge? Finally, this study posits that a few re-considerations, of the user and the way s/he is talked to by the software —and it's makers—, could be a very simple but important change towards a broader understanding of what is happening and why, with huge benefits for all involved.
# introduction :
A [foreword](http://tangible.tools/dissertation-introduction.html#foreword) and a [formal introduction](http://tangible.tools/dissertation-introduction.html#introductionformal) to this dissertation exist, but are not included in the academic longform for word count reasons. Accessible via sentence linktext.
This thesis deals with modern graphic design. It is written from a personal perspective on the field, and how I think it is understood. I feel like graphic design has become understood as purely utilitarian. A decorative function of communication. With the text, I follow an intuition the misunderstanding comes from the ways it is practiced, on computers, with computers and for a computer based distribution. I believe this misunderstanding exists inside and outside the field, but this thesis will concentrate on my perceptions as a designer from within.
Researching this intuition requires the investigation of three main points; firstly, the notion of craft. How can craft be defined, and how has it's understanding changed with the with the adoption of general purpose computers as tools. Secondly, a dive into the confusion between efficiency and efficacy in software tools. Efficiency being an avoidance of waste, efficacy being the ability to produce a desired effect. The interchangeability of these two notions lead me to understand the nature of some software tools, how they interface with me as a user, and how that interfacing effects the use and understanding of the tool. Lastly, the learning curve of alternative interfaces is considered, what the payoff of a more invested relation to software tools may be, and what I believe is at stake when interfaces try to dissapear.
The secondary thematic of this text is interfacing —as an active verb. I refuse to accept the constructs that make up the digital world as totalities, I rather see them as wrappers and conventions that masquerade as do-all solutions. I think the field of graphic design needs to adapt to being practiced on computers. Too often my tools try to mimick the physical traditions instead of harnessing the potential that computation can bring to graphic design. The industry must go beyond the digitally illeterate positions that industry standard software keeps it's users in. By this I mean that the access to digital litteracy is shared between softare makers and software users, but as a user I think I have much more to lose than software makers do.
Title: Chapter 1 — Defining ‘craft’ Date: 2017/01/02
= Defining ‘craft’ =
In ‘The Craftsman’, Richard Sennett is fast to give a definition of craftsmanship: « an enduring, basic human impulse, the desire to do a job well for its own sake ». As comforting as it is to be able to put craftsmanship back to a basic human impulse, still in the prologue, he states his two main theses: firstly « all skills, even the most abstract, begin as bodily practices; » secondly « technical understanding develops through the powers of imagination ». Without even needing to dig into the theses, Sennett shows that craftsmanship is somewhere within skills, technique, bodies and imagination.
<blockquote>A major argument of Sennett’s is the role of social order in the development of craft. Sennett states that an ancient ideal of craftsmanship is “joined skill in community” (51). Medieval Workshops, in particular, provided a communal atmosphere and social structure that guided the development of skill through “authority in the flesh” as opposed to knowledge “set down on paper” (54). There is an implicit authority in the workshop, a social order that values the “quality of skill” over “occupation of a place of honor” (61). The workshop binds people together as if forms a community of masters and apprentices. Quality and ethical codes of work are transmitted through such communities (and the guilds in which they participate) ensuring continuity while also allowing for creative developments through partnerships and communal participation. The medieval workshop began its demise with the Renaissance separation of art and craft. This separation emphasised the individual and her/his creation of “art” over communal development. The workshop became an inferior social space reserved for a lower class of society. <br><small>(Josh Sweeden, Ph.D. student in Practical Theology on ‘The Craftsman’, by Richard Sennett)<sup id="a1">[[#f1|1]]</sup></small>
</blockquote>
By the end of the 18th century / start of the 19th, we see the appearance of industrial capitalism. A capitalism of investments, that rests on a tight combination of technique and science. This will enable very high levels of production, by, not only, but importantly, enhancing productivity,<sup id="a2">[[#f2|2]]</sup> something we will come back to in chapter 2. Consequence of this is the destruction of a large portion (peasantry) of the population's physical health, not to mention it's wealth. The peasants then becomes proletarian, etc, etc. Our modern history has deconstructed craft. Away from the workshop, into the production chain.
<blockquote>Next, Sennett explores the implications of machines (replicants and robots) for craftwork. He ultimately shows how machines quickly were created for large-scale production, “gradually threatening the standing of the most skilled laborers and increased the number of semi- or unskilled workers.” Sennett affirms machinery for the sake of eliminating “unskilled, noisome tasks,” but claims that it is problematic when it “replace[s] high-cost skilled labor” (106). Instead of workshops, the new working community was steel mills and factories, and as such a new social structure was adopted, carrying different assumptions of appropriate work conditions as well as knowledge and authority. <br><small>(Josh Sweeden, Ph.D. student in Practical Theology on ‘The Craftsman’, by Richard Sennett)</small>
</blockquote>
20th century something new happens; consumerist capitalism. The notion of consumerism, is likened to Fordism at first, not to be confused with productivist capitalism which supposes the proletarisation of the producers<!--—the workers, that then become proletarian, who then would lose all of their professional know how-->. In the consumerist capitalism model it's not only the workers that lose their know how, the effects and effects on mentality extend to the consumers, who don't lose knowledge, but certainly lose their savoir vivre. I disambiguate slightly in historical context not to speak about software directly, but to be able to speak about the possibilities of craft within what software is.
It understandable and logical, in ways, why practice with software is not viewed today as a craft. First of all, by it's very nature, it is no longer a manual action. It starts and it ends on the same virtualisation apparatus that sees all sorts of other information and media. It's the same apparatus that a lot of people use today, for very many other tasks. The only real basis for materiality within software is analogy: a major portion of application software interface relies on analogies such as files, folders, documents, desktops, copying, pasting etc. All through the spectrum of software, from the seemingly simple to the complex and specific, we're asked to draw upon understandings of the physical world: paint brushes, paint buckets, pencils to perform actions that are going to be like what using those would be in the real world, but not really. When Sennett says that ''all skills, as abstract as they can be, begin as bodily practices,'' it's hard to imagine one being able to develop skills in the way that we understand them, thanks to Sennett, in a virtual world dependent on analogies.
It is also clear that Sennett's second thesis is hard to project in the world of software. One of the other specificities of software is that it is made by people attempting to solve to a problem, facilitate a specific task. The software maker defines boundaries, something that does not exactly stimulate imagination. This is not to say that technical understanding can not be acquired through the use of software, but again, the scope of that understanding is solely in the hands of the one making the intermediate. It's very simple to think of software only as a tool, and therefor, it has ‘single’ tasks.
We are looking at a (new) space for work that is extremely tailored. Computer programming is a sort of building by adding, in opposition to a manual craft which is more comparable to sculpting pre-existing materials. When an application that enables a virtual practice is programmed, the construction model is the other way around to the manual craft. The developer must consider what the premises for the practice are. She/he must develop an understanding of what the craft is, and how it can be interpreted by a computer. Then, by building, begin to answer all the needs of the (interpreted) craft. I would add that this, even when done properly, is only half the battle, the other half being the building of the communication devices that will give access to all that has been engineered. Access to the end user. Half of the job is in the interface.
I struggle to think of utilitarian software that does not have roots in some sort of craft. Even the most mundane computer tasks like file sorting, can have ways of doing that are the result of ''the desire to do a job well for its own sake''. If it didn't then we would have to ask operating system makers for alphabetical sorting, date sorting, logical directory structures, etc. There is a need for us to rethink what craft is today, towards digital craft, where the computer is as primary tool and environment. We have indeed lost physical tangibility, bodily actions and certain ways of imagination, but there is still enormous quantities of skill to be derived from the —re-imagined— techniques.
The difference between traditional crafts and digital crafts is that they have a different genealogy. A traditional craft builds upon itself, from itself. Sennett points to the importance of social order for craft. He speaks of communities of people in workshops and in same spaces. This relies on the existence of physical bodily actions, something that we gave up with software when we ‘agreed’ that machines would be faster and better than workers and craftsmen. I do however believe that it is towards a type of social order that we must look to start rebuilding an understanding of what craft is on-screen: the orders and hierarchy that we've built into computers. The logics that have been built in to computing systems, are a type of social order that we actually all respect as they are, we just don't really know about it; the orders don't make themselves apparent to the end user, but they can be simplified / understood as communications, requests and responses, managements and resource distributions. For us to be able to perceive quality digital practice as a craft, we must start by acknowledging and celebrating it's environment, how close it is to social order, how it came to be, and the immense amount of culture(s) and knowledge that makes it possible. We are part of this culture when we use computers. It is a relatively young culture, but one that is given to us, made to work for us to and helps us to better ourselves, so we must celebrate it. Then we can rebuild an appreciation for what is actually given to us through software. Logical as it is that software wants itself discreet and utilitarian, it is our job (but not only ours job, cfr chapter 3) to remind ourselves what is going on ‘under the hood’ on during the actions on screen.
If we can keep in mind how fantastic the sciences and progress that enable computers are, then we are closer to being able to feel the granularity that exists for and in all software, however seemingly simple or complex the interface.
One remaining aspect to address is the perception of quality within craft. Quality is important here because it gives us appreciation. Quality is as complex in manual craft as it is in digital craft. It is not the object of this study to attempt an explanation of what quality is, instead, I think that the embrace of an adversarial attitude to all the understandings and views of quality would be healthy. The fact that contemporary philosophy is still in discourse about how to distinguish certain kinds of qualities from one another, points to large diversity, range, needs, desires, morals, and cultures of different people. This same multiplicity is involved in digital cultures, so I can not pronounce on what quality digital craft is for all of it's realm. However the presence of —albeit differently understood— good and bad quality objects is beneficial to the understanding of digital craft. The discussion of what makes a quality software product is, in itself, helpful to highlight the granularity and ‘social’ layers I call for above.
To end off this chapter, I return to Sennett who gives us an example of his understanding of good quality modern craft:
<blockquote>Sennett does find hope in new developments of high technology. He cites the Linux Corporation which developed a sense of cooperation and collaboration among workers addressing problems. Instead of a framework of competition which establishes “clear standards of competition and closure…needed to measure performance and to dole out rewards,” Linux succeeded through “technological craftsmanship, the intimate, fluid join between problem solving and problem finding” (33). Linux revives a social space for craft similar to that of medieval workshops. It is attractive for people who aspire to be good craftsmen, who are “depressed, ignored, or misunderstood by [other] social institutions” (145).
</blockquote>
To refer back to the economic models noted over time —that were interrupting the quotes of Sennett's book at the start of the chapter— an other perspective on the different frameworks could be to call them ‘economies of contribution’: a contributive economy is an economy inside which those who contribute individuate themselves while contributing. This is the landscape, the Linux, free and open source software landscape, where skills and communities come back together to rebuild know how, rebuild quality in social manors, for the better of themselves, and for the better of all involved. I believe this to be what we should be looking and demanding for, in digital crafts.
-----
<b id="f1">1 </b>Josh Sweeden, Ph.D. student in Practical Theology on ‘The Craftsman’, by Richard Sennett: http://www.bu.edu/cpt/resources/book-reviews/craftsman-by-richard-sennett/ [[#a1|↩]]
<b id="f2">2 </b>Transcribed extracts from a Bernard Stiegler interview on Contributive economies: https://vimeo.com/32540487 [[#a2|↩]]
-----
= Table of contents: =
== [[#|Abstract]] ==
== [[#|Introduction]] ==
== [[chapter-1-defining-craft.html|Chapter 1 : defining ‘craft’]] ==
== [[chapter-2-efficacy-or-efficiency.html|Chapter 2 : efficacy or efficiency]] ==
== [[chapter-3-the-user-the-learning-curve.html|Chapter 3 : the user, the learning curve]] ==
== [[dissertation-conclusions.html|Conclusions]] ==
......@@ -3,14 +3,18 @@ Date: 2017/01/03
# Efficacy or efficiency
I absolutely believe that *imagination is stimulated by technical understanding* (McCullough, 1996), so we need for engineers to be *more legible* in their proceedings. When I say that I must take on attitudes of a traditional crafts-person, I mean that I need to take interest in all the ebbs and flows of my practice, and each of the tools that it involves. I believe that it is my task to take interest in all of the objects and constructs that build my digital environment. I do not mean with this that I must become prolific in the handling of all of them,[ref]I would think that there is a threshold or a balance point to be found, that would revolve around an ability to cartographically understand the schematics of a digital procedure in a digital space.[/ref] but having knowledge of their presence and workings can only better my understanding of my work environment, and my practice.
My belief is that we need less transparency between engineering layers, meaning more ways of understanding the constructs of our programs, more ways of seeing how our files, designs, creations, makings are recorded and understood by our computers. McCullough's demand for a program to be ‘increasingly transparent’ is fundamentally contradictory to his thesis, and extremely problematic. When I read ‘increasingly transparent’, I hear *less visible* — something which is currently happening across the board at the moment— but absolutely not something we need more of, especially in the desire for new craft recognition. I think that if there were to be a greater visibility of the granularity that is clearly present in programming, we would not only become better at what we are given access to, but we would gradually gain broader understanding of what we are working with, undoing the layers of abstractions of the virtual practice, and gain more ways of conveying our practice as the production of virtual objects.[ref]It would be interesting to consider different levels of transparency, levels that could be adjusted by the user to adjust how much of the internals I am seeing. Such a method may come to compliment a progression to the previous footnoted idea, about understanding software as schematics.[/ref]
<!-- ### intro + definitions -->
I feel like there may be confusion between attitudes of *efficacy* and *efficiency* in the software industry. The confusion exists on both ends: with the user and the maker. Efficacy is the power or capacity to produce a desired effect, effectivity, effectiveness. Efficiency is the ability to avoid wasting materials, energy, efforts, money, and time in doing. These two are closely related, but they are different visions for doing. I don't think this distinction is obvious in any visible way, from the users point of view at least. It is more related to an attitude and vision that the tool maker has of its user, her/his practice and way or reason for employing the tool. I think the misunderstanding of efficiency as efficacy has also come to further confuse our understanding of digital practices as abstracted crafts altogether.
<!-- ### easy intuitive fast — trade words -->
Today's commercial software makers are in constant competition. This is firstly due to the scarcity of commercial computing systems available, which in itself stems from the fact that there is essentially only one market of users to conquer. There are also multiple ways of delivering solutions in digital matters and often multiple implementations of said solutions. Boiling down competition benchmarks in this field comes down to two things: feature parity and ease; tentatively justifying in commercials how x solution or y product will bring more ease to a task. Software seems to be traded in terms of *Easy, intuitive, fast,* or even the ever simplistic *‘it just works’*. These qualifiers speak to the experience of use, rather than talking about the tools or tasks themselves. Speed, ease and good experience are what is sold to us, and this is what we are told we must expect.
Commercial software makers are in constant competition. This is firstly due to the scarcity of commercial computing systems available, which in itself stems from the fact that there is essentially only one market of users to conquer. There are also multiple ways of delivering solutions in digital matters and often multiple implementations of said solutions. Boiling down competition benchmarks in this field comes down to two things: feature parity and ease; tentatively justifying in commercials how x solution or y product will bring more ease to a task. Software seems to be traded in terms of *Easy, intuitive, fast,*[ref]http://www.trademarkia.com/zookware-fast-easy-intuitive-85648624.html[/ref] or even the ever simplistic *‘it just works’*[ref]https://youtu.be/qmPq00jelpc?t=8s[/ref]. These qualifiers speak to the experience of use, rather than talking about the tools or tasks themselves. Speed, ease and good experience are what is sold to us, and this is what we are told we must expect.
<!-- ### speed -->
Speed in accomplishing a task is a parameter of the historic, economic and ideological developments reviewed in chapter 1. The desire to do something fast, because I have other things that I need to do (fast) seems to descend from a capitalist mindsets preaching that time is money. In many ways, without some aspects of industrial capitalism, I probably would not be able to voice these opinions about and though these mediums, so I'm not saying speed or capitalism are the direct destructor of computing (comprehension or conscience); however, the consequences of a capitalistic view of products, solutions and tools for virtual practices have affected specific dimensions of software tools, mainly in their attitudes and articulations, which are now geared towards answering problems and answering them efficiently. Efficiency effects all interface elements, from menu labels, windows, to launching processes right through to document saving and exporting dialogues.
Speed in accomplishing a task is a parameter of the historic, economic and ideological developments reviewed in chapter 1. The desire to do something fast, because I have other things that I need to do (fast) seems to descend from a capitalist mindsets preaching that time is money. The consequences of a capitalistic view of products, solutions and tools for virtual practices have affected specific dimensions of software tools, mainly in their attitudes and articulations, which are now geared towards answering problems and answering them efficiently. Efficiency effects all interface elements, from menu labels, windows, to launching processes right through to document saving and exporting dialogues.
One example of this is the preliminary need to set a document type or size when using canvas based software. The very first steps, before any manipulation or any virtualisation, requires the user to plan the output of the session. Having to chose a reference size, a colour profile, even sometimes a preset template before any practice can happen reveals a tool that requires the user to set parameters, to get them out of the way, narrowing the frame to get done with the task faster.
......@@ -46,9 +50,7 @@ Gathering the procedures and methods that serve a user in accomplishing a task i
![invision](../images/invision.png)
<figcaption>↗ invision, a prototyping tool, says **DESIGN BETTER. FASTER.** (accessed March 2017) </figcaption>
I see efficiency as the demand of a production focused work environment. Efficiency in interface is the demand of modern *technology* (a term I have been avoiding, In order to prevent the field of product and service from moving too far from software and also because the term technology is a placeholder, a substitute for the industry to not have to deal with the specificity of computers → interfaces → technology). Modern software can't be mentioned without referring to solutionism funnelled through *technologies*. *“Technology is typically seen as a problem-solver, and well-designed technology *is supposed to follow an according aesthetic of efficiency*, ease and—ultimately—automation.”* (Morozov, 2013) It demands *better* methods for production: optimisation of resources —this view implies that there is a limit of supply, or that efficiency more often than not means trying to accomplish a task with fewer people and resouces. Theoretically speaking, this taylorist optimisation towards seamlessness is without end. When one portion of the production chain is optimised, other areas are then revealed to be less efficient. This leads to a vision of constant forwards motion, constant rethinking —which is another way of framing a second characteristic of capitalism; growth. The resulting attitude is the ideology of technologies and solutionism.
One final example of the confusion and how interpreting the language that results from it ends up hurting the user - software relationship is skeuomorphism. This subject had been addressed specifically here, but for word-count reasons it has been relocated to an [essay on Skeuomorphism on tangible.tools](http://tangible.tools/skeuomorphism-abstract-thought.html)
I see efficiency as the demand of a production focused work environment. Efficiency in interface is the demand of modern *technology* (a term I have been avoiding, In order to prevent the field of product and service from moving too far from software and also because the term technology is a placeholder, a substitute for the industry to not have to deal with the specificity of computers → interfaces → technology). Modern software can't be mentioned without referring to solutionism funnelled through *technologies*. *“Technology is typically seen as a problem-solver, and well-designed technology *is supposed to follow an according aesthetic of efficiency*, ease and—ultimately—automation.”* (Morozov, 2013) It demands *better* methods for production: optimisation of resources —this view implies that there is a limit of supply, or that efficiency more often than not means trying to accomplish a task with fewer people and resouces. Theoretically speaking, this taylorist optimisation towards seamlessness is without end. When one portion of the production chain is optimised, other areas are then revealed to be less efficient. This leads to a vision of constant forwards motion, constant rethinking —which is another way of framing a second characteristic of capitalism; growth. The resulting attitude is the ideology of technologies and solutionism. [ref]One final example of the confusion and how interpreting the language that results from it ends up hurting the user - software relationship is skeuomorphism. This subject had been addressed specifically here, but for word-count reasons it has been relocated to an [essay on Skeuomorphism on tangible.tools](http://tangible.tools/skeuomorphism-abstract-thought.html)[/ref]
![sketch](../images/sketch.png)
<figcaption>↗ sketch a digital design app, [...]**gives you the power, flexibility and speed you always wanted**[...] and makes you **Work better, faster** (accessed March 2017) </figcaption>
......
Title: Dissertation introduction
Title: Dissertation introduction longform outdated
Date: 2017/01/01
# Abstract :
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment