From: Humanist Discussion Group <willard.mccarty-AT-mccarty.org.uk>
To: humanist-AT-lists.digitalhumanities.org
Date: Tue, 30 Dec 2008 09:22:25 +0000 (GMT)
Subject: [Humanist] 22.413 thing knowledge
Humanist Discussion Group, Vol. 22, No. 413.
Centre for Computing in the Humanities, King's College London
www.digitalhumanities.org/humanist
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"
--[1]------------------------------------------------------------------------
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
--[2]------------------------------------------------------------------------
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.
yrs,
Stan
--[3]------------------------------------------------------------------------
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
explanation?
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
_______________________________________________
List posts to: humanist-AT-lists.digitalhumanities.org
List info and archives at at: http://digitalhumanities.org/humanist
Listmember interface at: http://digitalhumanities.org/humanist/Restricted/listmember_interface.php
Subscribe at: http://www.digitalhumanities.org/humanist/membership_form.php
Display software: ArchTracker © Malgosia Askanas, 2000-2005