Commit b007c533 authored by colmoneill's avatar colmoneill

deleted auto bak on spellcheck

parent 9c3c2ac8
Title: Chapter 2 — Efficacy or efficiency
Date: 2017/01/03
# Efficacy or efficiency
### intro + definitions
I feel like there may be confusion between attitudes of *efficacy* and *efficiency* in the software industry. The confusion exists on both end: the user and the maker / the vendor. This chapter looks at how the change that has happened in the conception of service tricked down to software, but also the conditions that makes it understood (or not) as a quality item, and how this change in service has come to influence what the user ends up seeking in her/his software tool. I think the misunderstanding of efficiency as efficacy has also come to further confuse our understandings of digital practices as crafts of abstraction and as practices all toghether. Efficacy is the power or capacity to produce a desired effect; effectiveness. Efficiency is the ability to avoid wasting materials, energy, efforts, money, and time in doing. These two are closely related, but they portray different visions of doing. I don't think this distinction is in any visible way obvious, from the users point of view at least. This has more to do with attitude and the vision that the tool maker has of it's user, her/his practice and way or reason for employing the tool.
### easy intuitive fast — trade words
Todays commercial software makers are in constant competition. This is firstly because of the few choices of commercial computing systems available, but also because there are multiple ways of bringing a solution to a problem when then matter is digital, and multiple implementations there of. I will boil down competition in this type of software to two things: feature parity and ease; justifying how x solution or y product will bring more ease to a task. Software is traded in terms of *Easy, intuitive, fast,* or even the ever aggresive *‘it just works’*. These qualifiers speak to the experience of use, rather than talking about the tool or task itself. Speed, ease and good experience, this is what is sold to us, and this is what we are told to expect.
### speed
Speed is an unfortunate parameter the historic, economic and ideologic developments that we reviewed in chapter 1. The desire to do something fast, because I have other things that I need to do (fast) descends from capitalist mindsets preaching that time is money. In many ways, without some aspects of industrial capitalism, I probably would not even be able to voice these opinions of and though these mediums, so I'm not saying it is a direct destructor of computing (comprehention or conscience); however, the consequences of a capitalistic view on products, solutions and tools for virtual practices have affected specific dimentions of software tools, in their attitudes and speakings, which are now geared towards answering problems and answering them efficiently. Efficiency ends up affecting all interface elements, from menu labels, windows, the launch of a process, right through to the way in which document saving and exporting dialogs are made. One example of this is the 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 color profile, even a preset template before any practice can happen is telling of a tool that wants you to get all practical out of the way, for you to get done with the task faster.
### example of speed, timeline
Another example is a slight difference in saving procedures between two of my most regularly used canvas based software tools, Gimp and Inkscape tells how each program imagines the user will deal with the outcomes of use. When my edits are done and I am ready to use my transformed file in other contexts, in Gimp, I must use a specific menu item labeled ‘Export as...’ that enables export to image file formats. The ‘File’ dropdown menu in Gimp also includes ‘Save’, ‘Save as...’ ‘Save a copy...’ before the export section. However, in Inkscape, the ‘Save as’ item is the one that I must use if I which to use the current file in other image formats.
There is logic to this difference, mainly due to the nature of the file formats and mediums that each program treats respectively, but the fact that Gimp asks to export delimits the space in which it was intended to act. This work has a timeline, and if you're hovering over the export menu item, you're very near the end of it. Keep in mind that typical export formats, jpeg, png, tiff, gif, are all formats that are accepted as initial input (through the import menu item, just a few lines down), so why this need to export? Meanwhile, Inkscape places static image formats inside it's general save menu, keeping *other use* formats and Inkscape augmented formats on a level playing field. The point of this example is not to compare the working of one tool versus an other, these are vastly different programs, respectively working in vastly different data and image types. The methods and working of the program of course descend from the different handelings of bitmap and vector graphics. Instead the example is to display how, in some software conceptions, manipulation happens in the only intent of having an output, being an item in a chain. The productivist mindest has a harsh effect on any exploration of a medium for it's own sake. The tool that asks for export does not speak of itself as an environment for manipulation and testing as much as it says that it is a set of procedures that are not valuable in other contexts than the ones they are intended in.
Example of multi window mode gimp ?
### object oriented speed
Non negligeable is another understanding that can be had of *rapidity* as in: processing *speed*. Traditional software (the kind that runs on your own machine, and your own local architecture, in opposition to off site cloud computing) has to deal with resource optimisation on a system level. Response to this management need leads to a way of building software called object oriented programming. In the background, programs get sectionned up into objects —a unique unchanging entity within the program complete with definitions of data and operations which it is permitted to carry out. The inner workings of the object, and interrelations between objects, are, as with most programs, hidden from the user. However, some inkling of their function can be gathered from what is visible at the interface and in use - in the division of the tools up into toolbars and in the various ways in which tools are shown to be able or not able to work on specific pieces of data. The use of toolbars is telling of this object orientation, and their groupings in similar funtions shows the set of scenarios that the user is allowed to leverage. (Fuller, 2000)
### example of toolbars, tooltips & narrative
A confusion between efficacy and efficiency is visible with some tooltips: I hover over the multiple toolbars in my vertor drawing application, for example, tooltips appear with only ever short sets of descriptors around an imperative form verb: ‘Create rectangles and squares (F4)’, ‘Create and edit text (F8)’, ‘Snap bounding box’. Instead of this language being a decription of what the tool can do, it speaks to me in terms of what the tool was meant to be used for. The simple turn of verb could suffice here, plain indicative present tense speaking of related objects would give descriptor sentences instead of orders: ‘Creates rectangles and squares (F4)’, ‘Creates and edits text (F8)’, ‘Snaps bounding box’.
Aside from this tonal obeservation, the incessant shortening of the legible language is beyond me. There is no reason for these tooltips not to be lengthened:
The only explanation I can come up with for this impertive speach is a desire to optimise space. Vector drawing programs, as other drawing programs, can and do get crouded with toolbars and windows. Is this the reason for the short text? To be out of my way so that I can get my job done? Might this space optimisation be a relic of the CRT monitor age?** I think that the reason for short text might be that the software views itself only as a type of automation of a process helping to get a job done. As fast as possible.
### Ease -> experience
Next as a sign of efficiency, *ease* comes as a promise of consideration —and premotition. If something is easy, it is efficient. For something to be efficient, it must be made easy. Easy is employed upstream, it is said to anticipate and comes to respond to *complex*, which is the most feared label for a software maker. Ease also is the entry point for the last of the terms trade I've isolated: experience. Gathering the procedures and methods that serve a user in accomplishing a task in software under the term experience is an way of ironing out of the specifics and the details. As many of the other ways modern software works, it constantly seems to be aiming to dissapear entirely, to be effortless, 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. Everything gathered under *experience* needs to be understood and unpacked as *interface*. (Lialina, 2014) My opinion is that we also need to unpack interface as communications. Interface elements give access to functions, but in doing so, they isolate the procedure to an item in an of itself. I think the field of user experience comes out of the fact that software interface has become a set of isolated procedures in which we forgot the start and the end of. We only know the action, not the transformation. This creates a great distance once more between what the user does, and what is actually happening. Interfaces of this sort add layers of opacity in order to achieve efficiency.
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 out of software, but modern software can't be talked about without mentionning solutionism funneled through *technologies*. 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. 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 solutionism. The build process of software seems indeed to follow an idea that it comes to solve a problem. The problem may be that text writing and text editing is repetitive, lenghty and wasteful on paper. Or it may be that manual arangement of image and text on the same surface requires lots of steps, specific machines, to produce a layout for print. Either way, these manual procedures exist(ed) and somewhere along the line, somebody took account of them and started to build a solution to a problem.
### Skeuomorphism
I don't believe solutionism in software has been active very long. Such perspective first needs consumers and a market, therefor the democratisation of the home computer likely accelerated the move to it. Meanwhile, a wider spreading internet access and multi device era really made way for the the thinking of software as applications. Apps as solutions, apps in a market place, app stores. “The is an app for that.” In this environment, I find it interesting to observe how vendors have been reponding to the enthusiasm with which consumers have adoped the devices that promise ease, while not necessarily being familiar with previous consumer computing environments. In the recent history of the iOS platform, a significant development meant that iDevices no longer needed to be connected to a fully fledged computer on initial bootup, they were ready to work as stand alone devices ‘out of the box’ albeit some account information and a network connectivity. This development meant that at least some customers were depending on these new devices to be all that they expected a personal computer would be able to do for them. I believe this to be the point of a massive challenge to the vendor and ease building into programs or apps, as it had to accomodate the spectrum of computer litterate to absolute beginners. I wonder if the vendors had ever had to consider such a wide range of users, but in the end products, we have keys to understand how the user is viewed by the vendor, through visual the communication. Skeuomorphism —being a sign of this— is a term used to qualify the visual imitation practice that copies typical or ornamental elements from physical counterparts onto the two dimentional screen. It imitates materials, textures and movement from the non computer world. I believe that skeuomorphism, even as a practice that is disapearing from the mainstream consumer computer, is telling of the considered position of the user, and her / his presumed ability to understand how software and applications are made.
The attempting to make interface easier by grounding it with skeuomorphism is deeply confusing to me. I understand these imitations in interface as enormous problems of communication. If the interface is to indicate to the user how the application is to be used, then it is disenchanting to think about why the visual skeuws were ever necessary. Imitating leather textures for a calendar application says to me that the software maker really could not trust me in understanding the words that the interface was displaying. I can not be trusted with my idea of what a virtual calendar is, it best have some leather around the edges so that I don't loose track of what it was intended for. Further, the use of a wood texture and a library shelf layout in a reader app can bring me to understand an other set of connected assumptions. For example the idea that I must keep all of my books, magazines and documents in the same place. That I have the luxury of displaying all of my books front covers, that for me to find my books amongst each other, they must have covers that are singular or legible enough to be identifiable, that readable mediums do not deserve sub classifications, or that books are finished objects, they meant to be read only, not manipulated, anotated, scribbled in, photocopied or torn apart.
All in all, the use of skeuomorphism itterates the power dynamic and hierarchic structure that exists in application type software, while constantly pushing the end user further down the process line. It repetidly insults the user cognitive ability, by assuming it is unable to conceive what an application may do. It sets boundaries for function by widening the gap in understanding that digital handelings can be viewed as crafts of abstraction. It talks to the user assuming that the simplest scenario is the best for all, ignoring any desire for more complexity or more granularity in options and processes. I find skeuomorphism to be revealing because when taken apart, it shows that the user is understood by the vendor as someone that is simple, same as the next user, and incapable of abstract thought.
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, encodings and virtualisations, 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 an view of digital practice only being solutions to problems. They tell us 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. 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 is not attainable though efficiency, but vendors want to portray computing as only a wa of being more efficient but not as a practice that can question and better fields. 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 solutionned by problem-solution cycles. I think we need to find other methods of working, in more consciousness, that will all necessitate a better understanding of the materials and the processes that happen on computers, all of the layers of abstraction that they include. I'm advocating for other ways because solutionism builds a hierachy, an ordering of people that gives some too much power over their users.
# References:
Fuller, Matthew, It looks like you're writing a letter: Microsoft Word, 5 Sept 2000
Lialina, Olia, Rich User Experience, UX and Desktopization of War, 7 November 2014
Dobbins, Michael, Urban Design and People, 1st ed. “for the answer before the questions have been fully asked” (New York: Wiley, 2009), 182.
<!-- 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 mutiple) (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 -->
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