Position statement

Position statement


This text serves to restate my position within the themes of my research here at the Piet Zwart institute. Following is a list of themes that have come up until to now, probably not totally inclusive: interfacings, tool access, craftsmanship, digital crafts, services - tooling & consequential products, need - services / specialists - responses, software issues, end user, modes of address, vendors, downstream, upstream, expertise, good practices.

Establishing a position from which to be able to speak (read: be critical) about these themes has been tricky. A lot of the debates included in these themes concern large demographics, groups of people that are refered to as 'the users', meaning pretty much everybody. I have felt somewhat uncomfortable about issuing comments on how I think these themes should engage with the general public because of this broad reach, and it's direct inclusion of general culture, general knowledge, and politics.

research field

Broadly speaking I am concerned about the propagation of digital/numerical cultures and practices in the impersonal top down mode of address they sometimes employ. More specifically, on our computers we now deal more and more (with) services, not programs. We have apps, not tools. In part I fear for the loss and appreciation of crafts, but mainly I fear that the opaque nature of some of the computer's proceedings ultimately means that the knowledge and doings of our machines in these proceedings becomes more specialised than they should really be. I fear that —on a bigger scale than day to day computer use— it is dangerous to indulge in the latest practices of usability, user experience and user interface, because they put productivity first, but proceedings last. If we, the common users, never are exposed to the ways the machines and programs work to effectuate the tasks we ask of them, we will be agnostic to the systems in place, ultimately making us unawarely dependent of —and on— them.

position restatement

As one can progress from software learner to software practitionner, I have also progressed from software user to software 'distributor'. The points that make one go from learner to practionner are degrees of mastery. I do not intend to call myself a master of anything, but within all the operations that a piece of software offers, some of them can be more or less mastered. Similarly, the points that make one progress from software user to software distributor are ones of service. More or less service. Tying together relative mastery and service is the notion of craftsmanship. This will come back later.

As this text is to state my position, I must start talking about myself —even more than I was before— which somewhat ruptures the flow. That being said, I am also going to be talking about modes of address, so I might as well switch around them right now.

The reson this became clearer to me was in review of my summer projects. Over the break between my two years, I took on projects and comissions for which I had roles. I knew these roles (and their expectations) from experiences had before joining the PZI program. I am a service provider for peoples digital/numerical needs or desires. I provide people with bundled tools and interface for them to accomplish the task they need to do, with concerns for efficiency and productivity. In this position, I am contributing to making computers less understandable to people, by taking the position of an expert. The middle man, the vedor.

The themes listed in the first
 § are related, but my navigation though them has been intuitive and non structured (which may have been a reason for the difficulty of placing myself in relative discourse positions) and it has been necessary for me to revisit this position of providing a service to someone to see that this makes me the software vendor that I have so many issues with.

It is from being the middle man that I can be critical. When I have the job of chosing and tayloring existing tools and processes for customers I also have the job of setting the degree of opacity on the process, like in Gimp. Then I interface the ins and outs of what people have to deal with, what people have to learn, and what I an automate for them, what I can make easier for them.

I should tell the story of when Drag and Drop really was like magic during the GRJ project. And remember the other stories too.

next section:
→ Notes on comfort(s)

tangible.tools is a site for projects and research by Colm O'Neill