[Humanist] 30.207 tools

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Wed Jul 27 07:46:32 CEST 2016


                 Humanist Discussion Group, Vol. 30, No. 207.
            Department of Digital Humanities, King's College London
                       www.digitalhumanities.org/humanist
                Submit to: humanist at lists.digitalhumanities.org

  [1]   From:    Andrew G Taylor <agt2 at rice.edu>                           (67)
        Subject: tools, tooling, and toolers

  [2]   From:    Benjamin Vis <B.N.Vis at kent.ac.uk>                         (13)
        Subject: Tools


--[1]------------------------------------------------------------------------
        Date: Tue, 26 Jul 2016 10:00:17 -0500
        From: Andrew G Taylor <agt2 at rice.edu>
        Subject: tools, tooling, and toolers
        In-Reply-To: <mailman.1.1469527202.19552.humanist at lists.digitalhumanities.org>


> Subject: [Humanist] 30.202 tools, method, tooling

Willard wrote "Can the aim of a research discipline be stability? Fixed methods? Would it be reasonable to think that the direction we're going in -- we who live at the crash-site of
computing and the humanities -- is far more about tooling, not tools, not methods? Of course people in CS will continue to discover cool algorithms that form part of the standard toolkit, but I am wanting to talk about discovering, not discoveries."

Hi Willard,

Creativity is as much defined by what we can and cannot do as what we want to do, our goals or ambitions. The tool is only as effective as the user.  As a technologist or "tooler" (often used in a derogatory way) I take various approaches to the tools I'm already familiar with to achieve my goals (of course I try to add to my toolset or replace faulty tools when necessary).

One digital tool I use is the browser-based Zoomify image engine.  The Zoomify team is always looking for ways to expand thecapabilities  http://www.zoomify.com/announcingV4.htm of the engine, but it does not follow that they are necessarily the best people at using that engine to create visualizations. why would they be?  It is their clients, the developers, who invest the time learning to use it on projects.  It is they who create the most impressive implementations as skilled "end-users."

This analogy might be of interest.  I am competent at playing blues on the diatonic harmonica, a very limited instrument. With training, perseverance and time invested over a number of years, I learned how to do it.  But the diatonic harmonica (1898 design) was never designed to be played using the blues techniques I learned.  The instrument (tool) was designed and built by Germans, but African-American artists had a different conception of music centered on the pentatonic scale and invented a different way of playing that same harmonica (bending reeds and other techniques) that the harmonica makers never imagined was possible.  The users expanded the possibilities of the tools, though over time the methods they pioneered have become "fixed" and overused.

Still, you have to "put in the time."  It took me at least four years to become an intermediate harmonica player competent in man of the idiosyncratic techniques (methodology?) of blues harmonica players.  Another wrinkle - many of the best artists were illiterate, and they were not very good at describing/how /they made their music.  Even with modern advantages (method books, better educated teachers) it still takes hundreds of repetitions before a technique can be used/meaningfully /(I use that word a lot these days) to create music.  Today there is design renaissance - craftsmen are making better harmonicas, and players like myself have to expand our end-user abilities if we want to take advantage of them.

In the same way, it takes time spent using a digital tool (not just learning it) to use it effectively and produce interesting work.  I've been using Photoshop for at least 15 years - I not only can use Photoshop, I can/play it/.  That requires an investment to do well, or even adequately.  Perhaps collaboration and sharing of work///and //ideas/  between people with disparate skill sets is required to create digital projects of value.  Is it a good time investment for humanities scholars to become expert technologists, or is division of labor a better solution?  There's always overlap, of course.

A tools effectiveness is a combination of the tool's capabilities and the extent to which I can use (and even distort) that tool.  I'm not going to pick up a guitar when I get inspired, because I'm much, much better at harmonica.  Theoretically over ten years I could learn to play the guitar, but right now that 1898 Marine Band is the better tool for me, despite all it's limitations.

Regards,
Andrew Taylor

> --[1]------------------------------------------------------------------------
>          Date: Mon, 25 Jul 2016 07:14:36 +0100
>          From: Willard McCarty <willard.mccarty at mccarty.org.uk>
>          Subject: tools
>
> Allow me, if you will, a stubborn course-correction, or an invitation to
> reconsider the current subject: not so much 'tools' as 'tooling', and not so
> much 'method' either. I'm clearly wanting to edge closer to the
> preoccupation of computer science with developing tools, and away from the
> help desk's helpful advice about which ones to pick up and use. But the
> concept 'method' has a very different trajectory'. The divergence is over
> the tendency of 'method' to become something fixed. (Consider, for example,
> "I have a method for doing that." Contrast "What if I try doing this?") What
> I am struggling to express is something very close to 'live coding'
> (https://en.wikipedia.org/wiki/Live_coding), something performative, for an
> audience of one. There are surely people here who know a great deal more
> about this than I do, but allow me to have a go.
>
> When I learned programming (Fortran, assembler) you had to plan everything.
> Flowcharts always; "one line of comment for every line of code" was the
> slogan I tried to live by. The reason for this now seemingly absurd amount
> of effort was that the 'turnaround time' -- itself a telling phrase -- could
> be hours, even days, and what you got back across the I/O counter in the
> computing centre was more often than not the result of some silly error in
> keypunching. (Once I received a call: "How many boxes of printout did you
> expect????") All that has changed, of course. You try things out.
> Experiment. Yes?
>
> I'm speaking about coding for research purposes. Are there stable methods at
> the edge of research, where it cuts into the unknown? Can the aim of a
> research discipline be stability? Fixed methods? Would it be reasonable to
> think that the direction we're going in -- we who live at the crash-site of
> computing and the humanities -- is far more about tooling, not tools, not
> methods? Of course people in CS will continue to discover cool algorithms
> that form part of the standard toolkit, but I am wanting to talk about
> discovering, not discoveries.
>
> And finally, a request: to use the wonderfully polysyllabic 'methodology'
> when it means something more than 'method'. Clearly the ghost of Thomas
> Sprat haunts me.
>
> Comments?
>
> Yours,
> WM
> --
> Willard McCarty (www.mccarty.org.uk/), Professor, Department of Digital
> Humanities, King's College London; Adjunct Professor, Western Sydney
> University
>
> Andrew Taylor, MLS
> Associate Curator, Visual Resources
> Department of Art History, Rice University
> 713-348-4836
> https://twitter.com/agrahamt



--[2]------------------------------------------------------------------------
        Date: Tue, 26 Jul 2016 19:31:35 +0000
        From: Benjamin Vis <B.N.Vis at kent.ac.uk>
        Subject: Tools
        In-Reply-To: <mailman.1.1469527202.19552.humanist at lists.digitalhumanities.org>


I much enjoyed reading Laura's contribution, and while I'm sure this was meant my extension, I'd like to add that the same (assumptions and treatments/preparations) apply to most data. Too often I find that the structure and/or classifications in which data is presented are taken for granted and then a taken for granted tool is applied on top of that. One may argue it is very counterproductive to start questioning the very nature of one's data, but I find that doing so actually already leads one to the design of tools that are commensurate with how that data/information is structured. I consider that a very important activity within DH, perhaps even something that could be called theory building within DH.

For me, an example of this causing friction is some of archaeology's adaptation of space syntax. Not only do I find the social theoretical basis (or 'necessity' in another word) for space syntax poorly argued and articulated (and not very often questioned), it was developed as a method/series of measure designed to aid production of better urban design. This, of course, doesn't preclude an analytical or interpretive value to its measures, but one should be asking the question: does this measure/tool suit my data and interest and is it capable of producing outputs in the same category as my purpose? Careful considerations of these ontological and epistemological questions may mean data needs to be restructured into units of analysis that need to be treated with methods/tools designed for these units, which need to be produce output fit for purpose by addressing the kind of questions/information that the purpose consists of or relies upon.

With this, I'm not (yet!) questioning the mathematics and zero's and one's digital tools would be based on, but definitely how these basics are appropriated to create digital research environments, (data) structures, and processes, and calling on researchers to ensure they are aware of what it means every step of the way. (In a way, how is a 'word' a 'word' and how does that suit or is that a necessity for purpose?)

Most digital tools to me are about searching, selecting, combining, collating, calculating, and overall (re)organisation (incl. visualisations), often in more complex and bigger ways than the human brain could feasibly achieve. Digital processing doesn't necessarily change the meaning of our data, it just teases out particular patterns and 'values' from them. This for me implies that the limitations to interpretation of our data that we started with (theories/hypotheses) still limit the output (reorganisation) produced by digital tools. It's where the frame of interpretation shifts one needs to be careful. The digital tool shouldn't change the theoretical framework (or the nature of a hypothesis), but contribute a view on it or add detail or possibly accuracy.

Anyway, I hope this makes sense to people on this list and might be of use as a thought and knowledge production process.

Laura, I was wondering what CS stands for in your contribution?

Best,

Benjamin

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

Dr Benjamin N. Vis | +44 (0)1227 82 <+44%20(0)1227%2082%20> 6543 | https://kent.academia.edu/BenjaminVis |

School of European Culture & Languages | University of Kent |

Rutherford College W3.E7 | Canterbury CT2 7NX | UK |

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :





More information about the Humanist mailing list