[Humanist] 22.413 thing knowledge

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Tue Dec 30 10:22:25 CET 2008

                 Humanist Discussion Group, Vol. 22, No. 413.
         Centre for Computing in the Humanities, King's College London
                Submit to: humanist at lists.digitalhumanities.org

  [1]   From:    "Hunsucker, R.L." <R.L.Hunsucker at uva.nl>                  (27)
        Subject: RE: [Humanist] 22.411 more on thing knowledge

  [2]   From:    Stan Ruecker <sruecker at ualberta.ca>                      (271)
        Subject: Re: [Humanist] 22.411 more on thing knowledge

  [3]   From:    Fernando Flores <Fernando.Flores at kult.lu.se>              (21)
        Subject: About "thing knowledge"

        Date: Mon, 29 Dec 2008 14:40:38 +0100
        From: "Hunsucker, R.L." <R.L.Hunsucker at uva.nl>
        Subject: RE: [Humanist] 22.411 more on thing knowledge

Martin Mueller schreef :  

> As for digital humanities, we need better doing and  
> making. Let's worry about the "theory" later.

If one thinks of a theory as a conception/suggestion 
of how the world works ( or, normally, how a quite 
limited aspect of the world works ) -- and should one 
*not* think of the matter in that way ? --, is the 
above then really such a good idea, I wonder ?

- Laval Hunsucker
  U. Amsterdam, UB

        Date: Mon, 29 Dec 2008 08:58:34 -0700
        From: Stan Ruecker <sruecker at ualberta.ca>
        Subject: Re: [Humanist] 22.411 more on thing knowledge
        In-Reply-To: <20081229062631.BA2F02AB13 at woodward.joyent.us>

I always hesitate before disagreeing with Martin Mueller, in part 
because he is a senior colleague I respect, in part because he writes so 
eloquently, and in part because he writes with such authority. 
Nonetheless, here goes.

Martin writes:

"What happens if now glorify the prototype by calling it a theory? Are
we going to get better prototypes? Almost certainly not."

It is sometimes hard to predict effects from knowing causes, but in this 
case, I would say the prototype as theory points us toward some clear 
advantages. One is that it allows us to ignore for a moment the standard 
features that are not the object of interest.

Let me provide an example. I was part of a group that thought it might 
have been a misstep to believe received wisdom that the best way to 
avoid information overload was to reduce the amount of information on a 
screen. What if we took an alternative route, and filled the screen with 
what Tufte calls "small multiples," but then attempted to reduce the 
perceptual or cognitive overload by also providing tools for 
manipulating the arrangement of all those objects? Would be people be 
overwhelmed, or, as I believed, reassured? It was hard to tell until we 
built some prototypes and tried them out with people. We haven't built 
many prototypes yet, and we haven't tried them out with very many 
people, but the early results suggest we get good results on measures of 
both performance and preference, for these kinds of interfaces, provided 
the collections are of the right kind and not too large.

Here is another example. We wondered if it was true that people in 
browsing objects on the screen would all tend to do it the same way, or 
if they would make roughly equal use of all the ways available to them. 
So again we built a prototype and tried it out. We provided 16 different 
facets of data and found that the people using the system logged roughly 
equal use of all 16 facets. I think for designers this has important 
implications, because what I was taught, at least, was that it was my 
job as a designer to figure out the one way to navigate the data that 
people would use 85% of the time, then build that.

In both these cases, the people using the system also mentioned that 
they would like all kinds of standard features. There should be a search 
function. There should be some way to save results and send them to your 
friends. There should be an annotation option, for both public and 
private annotations. And so on. Duly noted, I said. But because these 
were prototypes to test theories about people interacting with 
collections, I felt justified in saving the time and money that would 
have gone into building those other features. It is true those are good 
features--it has been well established that they are generally useful. 
In fact, it is so well established that I can't find anything 
contestable, defensible, and substantive to say about them. That is, 
there's nothing to publish about having included a search function, even 
if it is a great search function. You should have them in production 
systems. End of story.

Another advantage of calling a prototype a theory is that it reminds us 
to look for ways of evaluating the prototype other than as a lens onto 
something else. We can ask ourselves what theory this particular 
prototype is embodying, and whether there are other prototypes that 
embody it differently, and how do they compare? I included in an earlier 
note in this thread all the things I think we typically do with 
theories. In this case, it may suffice to say that if we think of 
prototypes as theories, we will want to analyse them, argue about them, 
put them to tests, and so on. I am always slightly disheartened whenever 
I give a paper or see a paper given that is largely descriptive, since I 
believe a better approach is analytical, and a better one yet is 
analysis with some data brought to the table in the form of some kind of 
trying it out with people.

I do agree with Martin that it isn't necessarily a good idea to call all 
implicit purposes theories, which leads me to what I believe is the 
third advantage of saying "a prototype is a theory"--namely that it may 
help remind us that theorizing by prototyping is different from building 
production systems, however elegant they may be. There is always a 
temptation to forget that thinking by building, as Richard Cunningham 
reminds us, is one of the things we are about.

Not very long ago now, I was co-supervising a very good graduate student 
who had built three very different prototypes. One day he arrived at a 
meeting with a fourth system, already built, that looked essentially 
like iTunes. I had to exercise what little diplomacy I had to point out 
that yes, this would work, but there was nothing new about it. It just 
addressed the problem from the current best practices. If I had 
explained to him earlier that a prototype is a theory, I think I could 
have saved him a lot of time and effort.


        Date: Sun, 28 Dec 2008 07:23:28 -0300
        From: Fernando Flores <Fernando.Flores at kult.lu.se>
        Subject: About "thing knowledge"
        In-Reply-To: <20081229062631.BA2F02AB13 at woodward.joyent.us>

I understand the relationship between the prototype and the theory as the relationship between intentionality and knowledge in the intentional act
known as work. Umberto Eco said that the meaning of an artefact is its
function. The meaning of an artefact or thing, reveals in
praxis. What is to say the same is that: if we have forgotten "how to do
with the thing" we can not grasp its meaning.
So, back to Willard McCarty's question (I quote): "Given the short  life-
span of software artefacts, our ignorance of how to read them  and,  as Peter
Galison has noted for non-verbal artefacts generally, their polysemous
existence beyond the meaning assigned by their creators, can any such
artefact ever stand for itself wholly without written  commentary and
My answer is no: To read old programming languages will be the same as to
understand dead natural languages; a question for specialists.

Yours, FF

Fernando Flores Moador
Associate Professor
Department of Cultural Sciences
Humanistic Informatics
Lund University

More information about the Humanist mailing list