HI Harry:
I don't disagree with the points in your "long" e-mail (another major
downside to IT is e-mail from everywhere when I least want it but at least
it save some trees, the bane of the copier). However, I still think you
have missed the boat, and it is the most common administrative blunder at
UCD; faculty do not need MediaWorks, but MediaWorks needs faculty, and
faculty live and work in academic departments. Thus, as long as IT
considers themselves as an essential campus service, your work will never be
of value to faculty because faculty do not have time to "go see" what you
are doing or why they would even want to talk to you (not to mention a
likely dislike for central services anyway).
My opinion is that technology in teaching will always be poorly used by the
general teaching faculty until IT services decide that the academic
department is the "home" of teaching, and that general central services are
as far, or farther, from teaching than any other entity on campus. Until
then, implementation will be done only by early adopters because they are
interested in technology itself. The only effective way to work with
faculty is to work "in" (note I did not type 'with') the departments that
are interested. How does one work "in" an academic department" One
identifies a specific opportunity and goes to the department with resources
an money in hand.
Today, the approach basically is (to use MediaWorks as the example):
MediaWorks has some neat things; come see us and we will help you; find some
money to pay for what you need or do it through our systems which are
designed for us not you; and teaching will forever be greater than anyone
could have predicted.
Step back and ask the question: this guy (a faculty member) is going to be
in the classroom 8 or 10 hours next quarter; maybe we should send someone to
his class for a few weeks and see what and how this guy teaches; maybe then
we should send someone to his department to see if we can help; maybe we
should try to assess potential applications of IT that would help this guy
with workload while also making the guy's style of teaching more effective;
and maybe, if the guy agrees to let us help, we should stick with the guy
like glue at least for two future rounds of teaching this class; oh, BTW we
should work with Teaching Resources to obtain financial assistance for the
guy, maybe even buy a couple of servers for the department just to get them
started.
Just a side note of my own experience late Spring Quarter, 2001; One: I
called MediaWorks with a request to meet with someone to discuss a teaching
project; I was asked to please hold while was connect you to XX; XX came on
line, I explained my request a second time and was told, oh I don't do that
but I will connect you to YY; oh, I see YY is not here at the moment but I
will have YY call you back. That was in June, I am still waiting. Two: I
called a specific section of IT that supports research; I left a message on
voice mail; the person returned the call within about two weeks and informed
my that what I was interested in was possible but some background work was
needed first (need to find the right guy) and I would by call you back.
That as in late June, I am still waiting. See another reason why early
adopters are the only ones willing to go into development - they are willing
to go it along.
An early adopter since 1969,
Graham
Graham A. E. Gall
Department of Animal Science
University of California
Davis, CA 95616
Office: (530) 752-1257
Fax: (530) 752-0175
E-mail: gaegall@ucdavis.edu
Web: gallweb.ucdavis.edu
-----Original Message-----
From: Harry R. Matthews [mailto:hrmatthews@ucdavis.edu]
Sent: Wednesday, August 15, 2001 8:51 AM
To: GAEGall@ucdavis.edu
Cc: John Bruno; Richard Plant; FIAT; Lana Moffitt; Jeffery C. Gibeling
Subject: RE: stress, technology and teaching
Graham and other Colleagues,
Yes. Why isn't there more effective faculty input into
usability testing of campuswide software?
This is a critical and timely issue for faculty members as
information technology moves beyond "pure" administrative
systems into the academic arena. Over the next few years we
will see new academic computing systems, such as course
management software, become an integral part of our
professional lives. Now is the time for us to influence the
campus direction in this area.
The AC4 (Academic Computing Coordinating Council) is
sponsoring a Symposium on Course Management Software with
speakers from other campuses (UCLA, UC Berkeley; UCSF; U.
Washington; U. of Indiana) as well as Davis. The one-day
Symposium is on October 3 in the Alumni Center and includes
substantial time for discussion by attendees. This is a
major opportunity for faculty members to have a say in the
choice of approach to course management software, and as
chair of the organizing committee, I urge you to join us and
provide your input. There will be more details circulated to
FIAT nearer the time.
I can think of several factors, related to faculty usability
testing, that we can address.
1. Faculty often don't realize the impact that these systems
will have on their professional lives until it is too late.
This has two unfortunate consequences. The first, and most
obvious, is that few faculty participate in the formative
stages of product evaluation even when the opportunity is
provided. The second, less obvious but maybe more critical,
is a consequence of the first. Those faculty who do realize
the importance of the formative evaluation stages are
typically "pioneers" or "early adopters" of technology.
Those of us who fall into this group are characterized by
enthusiasm for the technology itself and a willingness to
accept its limitations and frustrations because of the
"cool" things it can do (or promises to do). Are pioneers
and early adopters the people who should be doing usability
testing on behalf of the majority of the faculty, who are
much more pragmatic in their technology needs? I don't think
so -- at least not at Davis which is conservative in this
area (http://lead.ucdavis.edu). How can we get "pragmatic"
faculty involved in formative evaluation stages of new
academic information systems?
2. There are not many people who can be bridges across the
digital divide between the programmers and the users.
Bridges may not be prominent practitioners of either the
technology or the processes technology is intended to
support but "bridges" do understand both sides and can take
information effectively and bidirectionally from one side to
the other. Since the "bridge" belongs to neither side but is
between them, our local peer-review based reward system
breaks down because neither side recognizes the bridge
person as a true peer. Is it possible to make the position
of a "bridge" viable in our academic culture? My personal
experience is that this is not a viable role in Davis'
current academic culture. Until we cultivate and stop
penalizing those who act as bridges, we will continue to
have major problems with design and implementation of
academic information systems.
3. In a mature technology situation, the system design
process goes something like this: define the needs; build a
mockup of the user interface to meet these needs; write the
code; deploy. In contrast, we are in a very dynamic
situation with respect to academic information systems.
Users are not clear about what an information system can and
cannot do, and cannot properly define needs ahead of seeing
what the technology is capable of. Thus, there has to be an
iterative process of draft, review, re-draft and so on. This
is anathema to the technology side because it is seen as
"scope creep" or "feature creep" and plays havoc with
budgets. But it's the nature of this immature business.
4. An information system, by itself, doesn't help much, if
at all. It only helps if we the users are willing to modify
our processes. For example, when word processors came in, it
seemed terrible to many that faculty should consider doing
their own typing. Yet few of us would now go back to the
tedious process of hand correcting drafts and getting them
retyped in multiple cycles as multiple authors and reviewers
had input. Thus, an information system needs to be
accompanied by a fundamental re-thinking of our sacred
processes, which we have taken a lifetime to master, into
new ways of doing things. This always involves trade-offs
and may involve a temporary period of lowered efficiency.
There's a whole theory of "disruptive technologies" which
helped me understand this process better. How can we
accomplish this process re-engineering?
The primary mechanism on campus for leading these
discussions and bringing them to the attention of the
Provost is the Academic Computing Coordinating Council,
chaired by Professor Richard Plant and with 7 other faculty
representatives (both senate and federation). Its membership
is on its web site (http://ac4.ucdavis.edu).
Here at Mediaworks, we don't have responsibility for
campuswide information systems but we do provide extensive
services in support of teaching, research and
service/outreach. I have been very encouraged by the
willingness of busy faculty members to join the Academic
Advisory Board that I am convening to guide the development
of Mediaworks' services. I am determined that this Board
should be effective in aligning our resources with campus
needs. It meets the first 3 of the criteria below, and I'll
do what I can about the fourth.
To summarize, we need "bridges"; a willingness to undertake
an iterative design process; a willingness to re-think
academic processes; and a merit process that recognizes
these activities for both faculty and staff.
-- Harry
Harry R. Matthews
Professor and Director, IET Mediaworks
University of California at Davis
hrmatthews@ucdavis.edu
-----Original Message-----
From: owner-fiat@ucdavis.edu
[mailto:owner-fiat@ucdavis.edu]On Behalf Of
Gall, Graham A. E.
Sent: Tuesday, August 14, 2001 4:18 PM
To: Walters, Dick; fiat@ucdavis.edu
Subject: RE: stress, technology and teaching
My experience is the greatest stress comes from trying to
use campus based
technology, such as downloading grade rosters, finding what
I need, and
filing grades. For example, I and my staff have found that
Degree Navigator
has some nice things in it but for us, with over 800
undergraduates, the
system is completely digital while most if not all,
undergraduate records
must be on paper to facilitate faculty advisor needs. Can
you imagine
having 30 faculty with access to modify a students degree
requirements; I
can and have chosen to avoid the digital nightmare. In
other words, it is
possible to develop nice software, but not by software
engineers. I
anticipate next campus effort to standardize to some type of
"teaching"
software will be the next stress. As I learned in SITT some
years ago, if
you want it to work for you, develop it yourself.
Graham A. E. Gall
Department of Animal Science
University of California
Davis, CA 95616
Office: (530) 752-1257
Fax: (530) 752-0175
E-mail: gaegall@ucdavis.edu
Web: gallweb.ucdavis.edu
-----Original Message-----
From: Richard Walters [mailto:rfwalters@ucdavis.edu]
Sent: Tuesday, August 14, 2001 9:35 AM
To: fiat@ucdavis.edu
Subject: stress, technology and teaching
Good people:
Will Davis from TRC sent this along. hope none of you felt
stressed
by SITT!
dick walters
>From will.davis@ucdavis.edu Mon Aug 13 10:16 PDT 2001
From: Will Davis <will.davis@ucdavis.edu>
Subject: tech and stress article
Hmmm. Interesting. Keeping up with technology was ranked
as second
only to general time constraints for inducing stress. I
suspect
journalism faculty are no different than most.
Will
Friday, August 10, 2001
http://chronicle.com/free/2001/08/2001081003t.htm
Technology Causes Stress for Journalism Professors, Report
Says
By SUSANNAH DAINOW
Technology -- both learning to use it and trying to keep up
with it
-- causes journalism professors significant amounts of
stress,
according to a new report by
three researchers at the Indiana University School of
Journalism.
"Most journalism and mass-communication educators harbor
basically
positive feelings about the technology in their professional
lives,"
says the report, which
was released this week. "But that doesn't mean the
technology doesn't
bring stress as well."
The report is based on a study, conducted during the past
year, for
which the researchers surveyed more than 450 journalism
professors
and administrators
about their attitudes toward technology and about its impact
on their
professional lives.
Among six categories of stress factors, technology ranked
second only
to general time constraints in the amount of stress caused
to the
faculty members
surveyed, surpassing even worries about tenure and personal
issues.
For 73 percent of the faculty members and 74 percent of the
administrators, technology
caused a moderate or great deal of stress every day.
Technology-induced stress also contributed significantly to
job
dissatisfaction and burnout.
The study also found that 83.8 percent of the faculty
members
surveyed said that learning new technologies took time away
from
their research, with 71 percent
learning one or two new programs a year. Journalism
professors "are
an active learning group," the study reported.
Higher-ranking faculty members were more likely to feel
technology-induced stress than were their junior
counterparts; women
were also more likely than men
to feel tech stress.
Most faculty members agreed that they wanted and needed to
learn more
about using technology, but they felt that "the training
just isn't
sufficient," said
Christine Ogan, a professor of journalism at Indiana who was
one of
the authors of the report. "They're getting more training
than we
expected, but they still
say it's not enough for their needs."
Front
page |
Career Network | Search | Site map | Help
Copyright (c) 2001 by The Chronicle of Higher Education
--
* * * * * * * * * * * * * * *
Will Davis
mailto:will.davis@ucdavis.edu
Teaching Resources Center (530)
752-6050
17 Wellman Hall FAX: (530)
752-5986
One Shields Avenue
University of California,Davis
Davis, CA 95616-8717
* * * * * * * * * * * * * * *
This archive was generated by hypermail 2b29 : Tue Aug 21 2001 - 14:24:29 PDT