Commit 188644a2 authored by colmoneill's avatar colmoneill
Browse files

editing changes for full draft 2

parent 129199ca
......@@ -41,12 +41,12 @@ An other way of saying this might be that I wish ease in interface came with the
![patternry](../images/patternry.png)
<figcaption>↗ patternry, a front end design app, says **Designing consistent user experiences shouldn’t be that hard** (accessed March 2017) </figcaption>
Gathering the procedures and methods that serve a user in accomplishing a task in software under the term *experience* is a way of ironing out the specifics and the details, from the vending point of view. Meanwhile a flurry of new job titles have appeared to address the layering and renaming of procedures to interface to experience: Experience designers, User experience designers, User interface designers, Interaction designers, Product designers now all exist to address product communication in ways that are meant to keep the user enthused with what is happening on the screen. This creates a great distance once more between what the user does, and what is actually happening inside the computer. As many of the other ways modern software works, it seems to be aiming to disappear entirely, to remove any effort, therefor any thought. To be so fast that you don't see it work, or even think about the fact that it is doing work in the background. Seamless. We do need to remember that as much as the industry pushes the term experience, we are indeed here still talking about interface. (Lialina, 2014) Further, I believe that we also need to constantly remind that interface really is communication. Interface elements give access to functions, but in doing so, they isolate the procedure to an item in and of itself. I think the field of user experience is a result of software interface being a set of isolated procedures in which we forgot the start and the end points of. We only know the action, not the transformation. We know the verb, but not it's meaning. Interfaces of this sort add layers of opacity in order to achieve efficiency / efficiently.
Gathering the procedures and methods that serve a user in accomplishing a task in software under the term *experience* is a way of ironing out the specifics and the details, from the vending point of view. Meanwhile a flurry of new job titles have appeared to address the layering and renaming of procedures to interface to experience: ‘experience designers, ‘user experience designers, ‘user interface designers, ‘interaction designers, ‘product designers now all exist to address product communication in ways that are intended to keep the user enthused about what is happening onscreen. This creates a great distance once more between what the user does, and what is actually happening inside the computer. As is so often the case with contemporary software, the aim seems to be that is disappears entirely, to remove any effort, therefor any thought. The aim is to be so fast that you don't see it work, or even think about the fact that it is doing work in the background. Seamless. I do need to remember that as much as the industry pushes the term experience, we are indeed here still talking about interface. (Lialina, 2014) Further, I believe that we also need to be constantly reminded that interface really is communication. Interface elements give access to functions, but in doing so, they isolate the procedure to an item in and of itself. I think the field of user experience is the result of software interface being a set of isolated procedures of which we forget the start and the end points. We only know the action, not the transformation. We know the verb, but not its meaning. Interfaces of this sort add layers of opacity in order to achieve efficiency.
![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, to not widen the field of product and service too far away from software but also because technology as a stand alone term has no agency, it 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 talked about without mentioning 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 productions, an optimisation of resources —which is a view that entertains the idea that there is some sort of limit on supply, or that efficiency more often then not means trying to accomplish a task with less people, less resouces. I suppose that theoretically speaking, this taylorist optimisation towards seamlessness is without end, when one portion of the production chain is optimised, other areas then reveal themselves as 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.
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)
......@@ -56,39 +56,6 @@ One final example of the confusion and how interpreting the language that result
![adobeexpriencedesignadobeXD](../images/adobeexperiencedesign.png)
<figcaption>↗ adobe experience design, is built [...]**with innovative tools that eliminate speedbumps**[...] and let one **Design at the speed of thought.** (accessed March 2017) </figcaption>
This set of elements tell me that indeed there is a confusion in between efficacy and efficiency. I have the desire for computer programs to be effective in that they let us explore the natures of computing, encoding and visualisations, but there seems only to be efficient solutions that tell us that we must not take concern with being effective. Most of the language and communication that surrounds software and applications sell a view of digital practice only being solutions to problems. The consequence of the way they are designed communicate that it is not our place to take concern with any of the substances that compose the digital and networked world, we are to use objects that answer singular problems in singular fashions. We may not take interest in the specificities of mediums. In this way the solutionist mindset cultivates a barrier between maker and user. For the former to sustain, it is best if the latter does not know too much about the characteristics of the procedures, matter or natures of digital mediums. Ultimately, efficacy in digital practice might not be attainable because of the confusion with efficiency. Vendors end up portraying computing only as a way of being more efficient but not as a practice that can question or a process that can better various fields.
These elements tell me that indeed there is a confusion between efficacy and efficiency. I have a desire for computer programmes to be more open, to facilitate a user's exploration of the nature of computing, encoding and visualisations, but there seems only to be a demand for efficient solutions. Most of the language and communication that surrounds software and applications sell the view that digital practice is only about solving problems. The consequence of this design communicates that that it is not our place to be concerned with any of the substances that the digital and networked world are composed of, we are facilitated to use objects that answer singular problems in a singular fashion. We are not encouraged to take interest in the specificities of mediums. In this way the solutionist mindset builds a barrier between the maker and user. For the former to sustain, it is best if the latter does not know too much about the characteristics of the procedures, matter or natures of digital mediums. Ultimately, efficacy in digital practice might not be attainable due to the confusion with efficiency. Vendors portray computing as a way of being more efficient but not as a practice that can question or a process that can improve various fields.
The five screenshots above from Adobe XD, Sketch, InVision, Proto.io and Patternry show this portrayal, in it's commercial tone. I find myself to be very opposed to these procedures and solutions because I think computer culture is large and wild and needs not to be solutioned. I think we need to find other methods of working, in more consciousness, all of which will all necessitate a better understanding of the materials and the processes that happen on computers. We need interfaces and programs that reveal seams and boundaries, limiters, inputs and outputs so that we can build an understanding of some of the layers of abstraction that compose computers. We need programs and interfaces to help make the connections between the multiple tools they bring together and that show themselves as wrappers and containers of many entities, not stand alone magic boxes. Some examples of programs that show their inner composition or that exist to reveal their parts: [_playGnd](http://threejsplaygnd.brangerbriz.net/gui/), the XML editor in inkscape and the 3d page view in Firefox (details in chapter 3). I'm advocating for other ways because I find that the existing solutionism builds hierarchies, and orders users based on knowledge. Interface solutionism stops any curiosity and offuscates any visibility of the moving parts of a program. This experience and ease focused interface design produces a user that expects more from tools, while simultaneously stopping the potential learnin of digital literacy.
# References:
Fuller, Matthew, It looks like you're writing a letter: Microsoft Word, 5 Sept 2000 http://www.nettime.org/Lists-Archives/nettime-l-0009/msg00040.html
Lialina, Olia, Rich User Experience, UX and Desktopization of War, 7 November 2014 http://contemporary-home-computing.org/RUE/
Dobbins, Michael, Urban Design and People, 1st ed. “for the answer before the questions have been fully asked” (New York: Wiley, 2009), 182.
http://www.trademarkia.com/theres-an-app-for-that-77980556.html
<!-- This thread leads to the notions of productivity. The idea that methods can be employed to alter the speed of production. I think a lot of those trade words intutitive, easy, ‘just works’, are ways of talking productivity. The idea that a tool is trying to be efficient and get out of the way of production is interesting. I guess I can support it, if we were to think of a single utility hand tool, I can see how keeping it sharp and in good shape can aid my production, and the speed of accomplishing the task. But here is a gap. Software is very rarely only one tool. It's a collection of tools packaged together to practice multiple tasks of (possibly also multiple) (a) field[s]. A single hand tool speaks to us with it's materiality, with handles and indictions of how it is meant to be used. This is not to say that it must not be learned and mastered, but it is much more outspoken than the collections software tools that are summed up in icons, toolbars and tiny tiny tooltips.
In and of itself, productivity is not a bad thing, I'm simply saying that if it is the only language it employs to speak to the user, then it won't ever portray itself as a space for experimentation and leasure, it positions itself in a chain of events and not as a stand alone interesting object.
Productivity, it's place in software, how it continues proletarisation
Up to now in this chapter I have only been considering complex software, software for creation, software of abstracting craft. I stand by the idea that even utilitarian software has roots in processes that can be considered craft, however, the scope of software utilities is clearly narrower. By utility I mean calendar apps, contact management apps, note pads (simple text editors), calculators. I bring these up because they also clearly have a desire to get out of our ways, to get thigs written, events noted, etc. Still they need to distinguish themselves from one another, and they also want to be intuitive and usable. A difference here is the presumed knowledge of the user for utilitarian software is often more on par with reality than in the cases of complex software. These more simple programs are and have been, in my opinion, an other intersting case to look at the projection that software makers have of their users. -->
<!--
> *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.*
<br><small>To Save Everything, Click Here — Evgeny Morozov, ch 9</small> -->
<!-- It's a film made by a someone who thinks you're a smart as he is. -->
<!-- What is the criterium for well-designed visual production software? Is that criterium in line with the established understanding of digital craft?
Is there a larger misunderstanding in software between efficiency and efficacy? -->
<!-- It's important to remember that I'm arguing for the view that all software has a root in a type of manual work, and that that work got made abstract, somehow. So these trade words are primarely problematic to me because they presume a certain amount of preexisting knowledge of the task at hand, but presumes even more knowledge of the workflow that is expected in the abstract. -->
<!-- An efficiency focus problematises the understanding of software as a place for practice. I attempt to detail the ways in which I believe these problems to be observable above. Meanwhile, my discourse has looked mainly at functional and interpretational dimentions of some software. Up to now I've been outlining how the ways of talking about software reveals some build methods -->
The five screenshots above from Adobe XD, Sketch, InVision, Proto.io and Patternry show this portrayal, in its commercial application. I oppose these procedures and solutions as I believe that computer culture is vast and wild and it is limited through this solutionism. I think we need to find alternative working methods, in more consciousness of process, this would necessitate a better understanding of the materials and the processes involved in computer-based software design. We need interfaces and programs that reveal seams and boundaries, limiters, inputs and outputs in order to enable an understanding of some of the layers of abstraction that computers are composed of. We need programs and interfaces that help to make the connections between the multiple tools they bring together and that show themselves as wrappers and containers of many entities, not stand alone magic boxes. Some examples of programs that show their inner composition or that exist to reveal their parts are [_playGnd](http://threejsplaygnd.brangerbriz.net/gui/), the XML editor in inkscape and the 3d page view in Firefox (details in chapter 3). I'm advocating for alternatives as I believe that solutionism builds hierarchies. Interface solutionism prevents curiosity and obfuscates the visibility of the moving parts of a program. Ease focused interface design produces a user who expects too much from their tools, and thus becomes increasingly dependent upon these tools while also preventing opportunities for the improvement of the user's digital literacy.
......@@ -3,41 +3,30 @@ Date: 2017/01/04
# The user, the learning curve
Asking for interfaces to reveal the programs they use comes with requirements. Mainly the will to learn about these computer structures. The learning curve .........
Requesting that an interface become more open in the programs that it uses implies greater investment from the user. It would become necessary for a user to learn the basic procedures enabled by the interface. Such an interface method expects the user to have some motivation towards learning the ways of computers and information systems. Learning this somewhat invisible material/procedure that the software system is comprised of is not always *easy* or necessarily always logical, but a payoff of the learner's investment is a much greater agency across the spectrum of computation. Following are some examples of interfaces that strike a balance between usability and visible seams.
![_playGnd](../images/_playGnd.png)
<figcaption>This interface enables the creation of 3d objects that can be easily embedded on web pages. The tool proposes to start with the graphical user interface, but each value that is changed or tweaked automatically updates in the code view the is flush left on the screen. This dual attitude of code and interface shows the user how each object is encoded and reflected by the interface, in the code. It's a great tool for learning the 3D web languages. (accessed March 2017) </figcaption>
<figcaption>This interface called _playGnd enables the creation of 3d objects that can be easily embedded on web pages. The tool proposes to start with the graphical user interface, but each value that is changed or tweaked automatically updates in the code view that is flush left on the screen. This dual attitude of code and interface shows the user how each object is encoded and reflected by the interface, in the code. It's a great tool for learning the 3D web languages. (accessed March 2017) </figcaption>
![Inkscape's XML editor pannel](../images/inkscape-xml.png)
<figcaption> text describing inkscape xml (accessed March 2017) </figcaption>
<figcaption>The pane open on the right side of this capture is called the XML editor. Inkscape is a vector drawing program that records drawing data in the Scalable Vector Graphics (svg) language along with some wrapping of the svg language in Extensible Markup language (xml) to save file names, some preferences, profiles etc. This pane lists and updates a text view of the objects you draw by using the toolbar tools. It splits object types and their attributes (type, scale, position, transformations) into legible tables. Along with this, it lets you manipulate the xml file, with keyboard and text editing procedures, to continue the creation of your drawing while manipulating the code it is recorded as.(accessed March 2017) </figcaption>
![Firefox's 3d HTML view](../images/firefox3D.png)
<figcaption> text describing 3d view (accessed March 2017) </figcaption>
<figcaption>This 3d view is a feature inside the web inspector that is built into the Firefox web browser. Hypertext Markup Language is a way to tag portions of text for hierarchy of a document. The Browser can then read the markup and visually render the hierarchy that has been encoded. Web inspectors let users and website makers review how their html is being interpreted by the browser. Firefox takes this one step further by offering this 3d view of the html document, by layering enclosed and nested items over one another. The 3d view lets you click on the different visual layers to see what the element stack is, displaying HTML exactly how the browser reads it, but letting the user look at a third dimension rendering, for clarity and understanding.(accessed March 2017) </figcaption>
I find this type of interface extremely interesting and nourishing. These examples follow many of the established communication and interface conventions, but offer alternative positions, informing the user of the computer language and proceedings, augmenting the interface to be an exploratory, interesting object in itself. To this point I've been advocating more verbosity and transparency in interface. The examples above highlight the potential of an interface as a tunnel through abstraction layers. They make space for interfaces to become exploratory, wherein some elements are present purely to inform, for browsing purposes, I use the term browsing here in much the same way as [Adele Goldberg does in the presentation documents for one of the first graphical user interfaces; Smalltalk](https://youtu.be/AuXCc7WSczM?t=1m32s): in which browsing is emphasised because “too often we think of computers as being very precise machines, in which we have to very precisely say I want this or that and you get it back, exactly what you asked for. But the nice quality of a library [browser] is that you can walk around looking for something specific, but as you do that, you find other things, and that's what browsing is all about.” (Goldberg, 1979)
Goldberg and Smalltalk were prolific during the early 80s, a period when the computer was no longer reserved only for scientists or engineers. Personal computers were thought to extend towards other fields, other crafts could benefit from computational power. The work of Goldberg and Alan Kay (a fellow researcher within the Learning Research Group at Xerox PARC) on graphical user interfaces was never meant to obfuscate code, to hide it from the user, as it is on other commercial computer systems today, it was meant to augment the code to help you program. Windows and Apple, whose commercial activity was spawned from the work at Xerox, chose to ignored the metamedia concept (detailed below), instead, simply imitating old media. Movies, Music and books would eventually become .mov, .mp3 and .pdf on the computer, not all that different from their analog counterparts (Briz, 2016). In contrast, for Goldberg and Kay, the computer was an active medium which could “respond to queries and experiments, so that the message may involve the learner in a two-way conversation. This property has never been available before except through the medium of an individual teacher. We think the implications are vast and compelling [...] a new kind of medium would have been created: a metamedium, whose content would be a wide range of already existing and not-yet-invented media.” (Goldberg and Kay, 1977)
There is one important constant in all of the development of computers: the user focus. The progress of computer sciences, but also of electronics and network infrastructures over the years are extremely important and key elements of this development, but it's the humans that make and the humans that receive development that are the reasons of and for the flourishing of computers as a cultural space.
Unfortunately, it is hard to find many embodiments of the working methods for interfaces Goldberg and Kay set out in 1977. Teaching and learning is not a concern for modern interfaces. I am concerned by this lack of focus for learning as I find myself stuck between the effects of solutionist interfaces. In that light, a simple overview of the structure of the “parties involved in the configuration of software, services and it's [...] implications on the world” is helpful. These are: “1) developers and operators, i.e. the parties who develop software, architect services and operate the cloud infrastructure. Typically, service operators themselves use other services for development and may integrate services into their offering to their customers; (2) Curators, i.e. the end-user-facing entities that integrate software structured as services into their own operations (they include so-called enterprise customers). Curators pick and choose which services to use with implications for their end-users. These curators can be IT departments, local web development teams or individual developers; (3) End-users, i.e. the individual users, consumers, employees, workers, students, patients, audiences, who are affected by the structuring of software as services.” (Gürses and van Hoboken, 2016)
In that light, a simple structure of the “parties involved in the configuration of software, services and it's [...] implications on the world” is necessary for analysis. These are: “1) developers and operators, i.e. the parties that develop software, architect services and operate the cloud infrastructure. Typically, service operators themselves use other services for development and may integrate services into their offering to their customers; (2) Curators, i.e. the end-user-facing entities that integrate software structured as services into their own operations (they include so-called enterprise customers). Curators pick and choose which services to use with implications for their end-users. These curators can be IT departments, local web development teams or individual developers; (3) End-users, i.e. the individual users, consumers, employees, workers, students, patients, audiences, who are affected by the structuring of software as services.” (Gürses and van Hoboken, 2016)
Within this structure, I am the middle-man, the curator, and it is from this position that most of the development of my thoughts around the communication issues within interface have been spawned. My work as an independent graphic designer and website developer involves the choice and implementation of pre-existing tools and processes for others to publish their content. But the more I do work as middle-man, the more responsible I feel for the digital literacy I expect of the end-users I produce for. This leads me to question the potential for the acquisition of this kind of literacy, with regards to people (customers / collaborators) who spend a lot of time on computers despite my services.
Within this structure, I am the middle-man, the curator, and it is from this position that most of my thought development around the communications issues of interface have spawned. My work as an independent graphic designer and website developer involves the choice and implementation of pre-existing tools and processes for others to publish their content. I think it is important to restate my position here because all the subjects I've been looking at up to now in this dissertation are various constructs of related communication that give more or less access to culture and functionality. Related communication happens all of the time in interfaces. In fact, it is the basis of it, but the horizontal nature of this communication is for me the key to many issues I've looked at. In the last chapter I covered some examples of types of speech that exist in interfaces, short sentences that are statements of designed functions as facts, without any context to them. They also have signs of dialogue speech but with absolutely no way of identifying who the interlocutors are supposed to be. I'm finding that a lot of the communications in interface is left up to conventions, themselves not exactly well thought through methods. The tool tip here comes back to mind. It acknowledges the need for more extensive information of a tool, but bypasses all of the communication needs very rapidly. It's just a tip I suppose, but it acts more like a theatre prompter, just a few words to recite a text you're supposed to know from ulterior studies. I'm also finding that as software interfaces rely on a mix of visual and language to communicate, it never considers the job of teaching. Interface builds upon ideas, analogies, ease and experience, but it never acknowledges the fact that some of it's users are experts, and some are beginners. It's very inflexible as a two way machine.
Furthermore in the interest of experience and seamlessness, all interfaces end up looking like each other and adopting each others characteristics. Consistency is actively thought of and encouraged as a way ‘*for users to be able to transfer their knowledge and skills from one app to another. The principle of consistency holds that an app should respect its users and avoid forcing them to learn new ways to do things for no other reason than to be different.*’ (macOS Human Interface Guidelines, 2017) But this is a teaching that assumes that predeceasing apps have gotten everything right and that all the knowledge that users need exists already. The fact that it discourages alternate approaches limits diversity which also raises a huge flag for me. The term consistency is one amongst many others within these guidelines: Forgiveness, Aesthetic integrity, Metaphors, Mental models, all of these principles are documented and spoken of as the singular way to make software interfaces. They exist within the world of macOS, which openly states that it believes that technology should be transparent. Meanwhile, my vision for the better communications of interfaces rely on visible seams. When OSx says transparent, they mean to make componentry invisible. I believe the opposite needs to happen, that we must make models that are heterogeneous, and build interfaces that make some homogeneity for functions. The confrontation in the video below makes these visions clearest, in the words of the company itself:
These notions of experience and seamlessness seem to be responsible for the lack of literacy mentioned above. The result of these notions is that these interfaces end up looking like one another and adopting one another's characteristics. Consistency is actively encouraged as a way ‘*for users to be able to transfer their knowledge and skills from one app to another. The principle of consistency holds that an app should respect its users and avoid forcing them to learn new ways to do things for no other reason than to be different.*’ (macOS Human Interface Guidelines, 2017) However, this statement relies on the assumption that previous apps have gotten everything right and that all the knowledge that users need exists already. The fact that it discourages alternate approaches limits diversity. Diverse interfaces are necessary in order to promote diverse approaches to different practices. If all methods become and feel similar, it stands to reason that outcomes will become similar. The term consistency is one amongst many others within these guidelines: Forgiveness, Aesthetic integrity, Metaphors, Mental models, all of these principles are documented and spoken of as singular ways to make software interfaces. They exist within the world of macOS, which openly states that it believes that technology should be transparent. In opposition to this, my vision for better communications within interfaces relies on visible seams. When OSx says transparent, they mean to make the components of an interface invisible. I believe the opposite needs to happen, that we must make models that are heterogeneous, and build interfaces that make some homogeneity for functions. The confrontation in the video below makes these visions clearest, in the words of the company itself:
<video controls="" poster="http://contemporary-home-computing.org/art-and-tech/not/material/mcluhnik.jpg" height="405" width="100%">
<source src="http://contemporary-home-computing.org/art-and-tech/not/material/09.webm" type="video/webm">
<source src="http://contemporary-home-computing.org/art-and-tech/not/material/09-web.mp4" type="video/mp4">
</video>
“The user becomes an object, but at a peculiar position in the hierarchy of others. It is excluded from the internal transmission of information, and instead allocated representations of elements of this information as interface. This information is allocated on the basis of how closely it corresponds to the 'tasks' that users have come into composition with the software to perform.” (Fuller, 2000)
Apple inc encourages consistency for ‘user to be able to transfer their knowledge and skills from one app to another’ in their interface guidelines. They seem to confuse iterface knowlegde and computer litteracy repeatitly with this attitude. One may be able to re-use an interface trick from one app to another, but this is only ported conventions, not actual knowledge or skill. The consequence of the consistency of the interface conventions that are nurtured is regularity and therefor, a sense of comfort. I believe that a comfortable, regular interface destroys propencity towards digital litteracy. Comfort means that everything has been taken care of for the user, and she/he has absolutely no questions to answer or to ask. Comfortable interface accompliches the task of dissapearing completely and leaves no space for learning (apart from interface conventions) the litteracy of digital practices and crafts.
# References:
Seda Gürses and Joris van Hoboken, 'Privacy After the Agile Turn, in: Selinger et al (eds.), The
Cambridge Handbook of Consumer Privacy, Forthcoming 2017. Available at https://osf.io/ufdvb/.
Fuller, Matthew, It looks like you're writing a letter: Microsoft Word, 5 Sept 2000 http://www.nettime.org/Lists-Archives/nettime-l-0009/msg00040.html
https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/DesignPrinciples.html#//apple_ref/doc/uid/20000957-CH18-SW1, accessed February 2017
Apple inc encourages consistency for ‘user to be able to transfer their knowledge and skills from one app to another’ in their interface guidelines. They seem to confuse interface knowledge and computer literacy repeatedly with this attitude. One may be able to re-use an interface trick between one app and another, but this is only ported conventions, not actual knowledge or skill. The consequence of the consistency of the interface conventions that are nurtured is regularity and therefor, a sense of comfort. I believe that a comfortable, regular interface destroys a propensit for digital literacy. Comfort means that everything has been taken care of for the user, and she/he has absolutely no questions to answer or to ask regarding the procedures. Comfortable interface accomplishes the task of disappearing completely and leaves no space for experimenting (apart from interface conventions) the literacy of digital practices and crafts. Apple is not the only company that works in this way, but they are the most successful at the moment, and in my network, unfortunately the most present.
Title: Dissertation conclusions
Date: 2017/01/05
Status: draft
# Conclusions
> Sennett further notes the inadequacies of written language to “depict physical action” (179). Laboratories and workshops become the exemplar, places where “the spoken word seems more effective than written instructions” (179). Sennett also illustrates this point by examining the how-to instructions of various chefs. Ultimately, the instructions that show, rather than tell, provide the best experience and results for the novice cooks. In these cases, however, showing was not done by physical presence per se, but through narratives and metaphors which “give each physical action [of the recipe] heavy symbolic weight” (193).
With this dissertation I attempt to understand the factors made and that make software plainly utilitarian. The economic dimensions always seem omnipresent as an uphill battle, but I'm too exited about the potentials of computers and software to give up on the fight for “cultural software” (Lev Manovich, 2011). Moreover I'm motivated by movements that question the political and social elements that are translated into the technical domain. "The computer world deals with imaginary, arbitrary made up stuff that was all made up by somebody. Everything you see was designed and put there by someone. [...] There are so many ideas to care about, and with ideas comes the politics of ideas." (Nelson, 2012)
> Ultimately, I find The Craftsman to be a compelling argument for the dynamic matrix-like development of knowledge, character, and community. All three of these, Sennett argues and I agree, are severely damaged when work is not understood as craft.
I hope to have addressed indirectly the situation of computer illiteracy and made a stance for what we users should be demanding. I am simply weary of interface constructs that seem to make the learning of the behind the scenes elements harder because they have no reason, and therefor make me think that there may be a hidden agenda in these practices. This suspicion is probably more often false than true, but is a growing concern stemming from “the Agile Turn”(Gürses and van Hoboken, 2016). Confirming this statement is not an area I want to research, for fear of what I might find, but the example of ways in which lack of functional computer knowledge is leveraged for a solutionist financial gain occur very often online and across digital services. They offer something for free, but get a lot more out of the data that is harvested from their user base. These are reasons why I advocate for wider spread knowledge of the functioning of information systems. Meanwhile, in and for all of this the *learning* aspects are key, and it is with the ideas of learning and spreading knowledge that I stay motivated.
To state this opinion clearly: I am not holding the position that every human must learn computer architectures and programming languages. What I am calling for are interfacing methods that do not aim for seamlessness, that reveal their parts, toggling between heterogeneous and homogeneous displays, and that trust their users as equally smart as the software builders. I do not believe that everybody must be on similar technical levels of understanding computer technologies either, but I do think that a broader and better understanding of all of the types and all of the layers of abstractions that are needed for computers and networks to function is, in my opinion, a valiant way forwards.
---
# Table of contents:
## [Abstract](/dissertation-introduction.html)
## [Introduction](/dissertation-introduction.html)
## [Chapter 1 : defining ‘craft’](/chapter-1-defining-craft.html)
## [Chapter 2 : efficacy or efficiency](/chapter-2-efficacy-or-efficiency.html)
## [Chapter 3 : the user, the learning curve](/chapter-3-the-user-the-learning-curve.html)
## [Conclusions](/dissertation-conclusions.html)
---
Title: Thesis references
Date: 2017/01/06
# References:
<!--
EXAMPLE BOOK
Author, Initials., Year. Title of book. Edition. (only include this if not the first edition) Place of publication (this must be a town or city, not a country): Publisher.
EXAMPLE WEB
NHS Evidence, 2003. National Library of Guidelines. [online] Available at: <http://www.library.nhs.uk/guidelinesFinder> [Accessed 10 October 2009].
EXAMPLE JOURNAL OR MAGAZINE
Authors, Initials., Year. Title of article. Full Title of Journal or Magazine, [online] Available at: web address (quote the exact URL for the article) [Accessed date].
Kipper, D., 2008. Japan's new dawn. Popular Science and Technology, [online] Available at: <http://www.popsci.com/popsci37b144110vgn/html> [Accessed 22 June 2009].
EXAMPLE VIDEO
Mrgeorged, 2009. Top Gear The Stig revealed Full. [video online] Available at: <http://www.youtube.com/watch#!v=eTapK5dRaw4> [Accessed 23 June 2009].
-->
* Sweeden Josh, 2009. Craftsman, by Richard Sennett | Center for Practical Theology [online] Available at: <http://www.bu.edu/cpt/resources/book-reviews/craftsman-by-richard-sennett/> [Accessed November 2016]
* Stiegler Bernard, 2012. ITW Geek Politics Bernard Stiegler. [video online] Available at: <https://vimeo.com/32540487> [Accessed September 2014]
* Broeckmann Andreas, 2001. Review: Abstracting Craft: The Practiced Digital Hand by Malcolm McCullough, Leonardo, [online] Available at: <http://www.jstor.org/stable/1576995> [Accessed November 2016]
* McCullough Malcolm, 1996. Abstracting Craft: The Practiced Digital Hand. Cambridge, MA: MIT Press.
* Sennett Richard, 2008. The Craftsman. New Haven, CT: Yale University Press.
Fuller, Matthew, It looks like you're writing a letter: Microsoft Word, 5 Sept 2000 http://www.nettime.org/Lists-Archives/nettime-l-0009/msg00040.html
Lialina, Olia, Rich User Experience, UX and Desktopization of War, 7 November 2014 http://contemporary-home-computing.org/RUE/
Dobbins, Michael, Urban Design and People, 1st ed. “for the answer before the questions have been fully asked” (New York: Wiley, 2009), 182.
http://www.trademarkia.com/theres-an-app-for-that-77980556.html
Seda Gürses and Joris van Hoboken, 'Privacy After the Agile Turn, in: Selinger et al (eds.), The
Cambridge Handbook of Consumer Privacy, Forthcoming 2017. Available at https://osf.io/ufdvb/.
Fuller, Matthew, It looks like you're writing a letter: Microsoft Word, 5 Sept 2000 http://www.nettime.org/Lists-Archives/nettime-l-0009/msg00040.html
https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/DesignPrinciples.html#//apple_ref/doc/uid/20000957-CH18-SW1, accessed February 2017
Briz, Nick, Video essay, The Browser: how it became the artist's modern canvas, accessed March 2017, available at https://www.youtube.com/watch?v=bRCgREBrcTo
Goldberg, Adele and Kay, Alan, Personal Dynamic Media, original publication: *Computer* 10(3):31-41. March 1997. Available in The New Media Reader, 393-404, http://www.newmediareader.com/book_samples/nmr-26-kay.pdf
Goldberg, Adele, Smalltalk-80 in interview, available at https://www.youtube.com/watch?v=AuXCc7WSczM, accessed March 2017.
Manovich, Lev, 2011, Cultural software,
- Ted Nelson, The Myth of Technology/Computers for Cynics(2012)
https://www.youtube.com/watch?v=KdnGPQaICjk
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