Panels >> The Experts Discuss
Syllabus2004 attendees examine new challenges and issues with the help
of campus peers and pros.
Is Open Source in Your CMS Future?
A venerable panel—and an audience technologically equipped for interaction—take
on the big questions about open source.
As course management systems have matured, they have encompassed wider functionality,
and been integrated with numerous other campus systems. As with most large and
complex systems, the unbundling of service and software components can produce
greater opportunities for efficiencies and customization. No wonder, then, why
open source efforts in general, and specifically Sakai, may be the wave of the
future for CMS.
The following discussion of this topic was excerpted from a July 19, 2004 plenary
panel at Syllabus2004. Victor Edmonds, director of Educational Technology Services
for UC-Berkeley (opposite page, left) moderated the discussion,
and utilized TurningPoint “personal response” software from Turning
Technologies (www.turningtechnologies.com),
to engage attendees in interaction during the conversation. Session panelists
were (above right, left to right): Charles Kerns, educational technology manager
for the Sakai project at Stanford University (CA); Phillip
D. Long, senior strategist for the Academic Computing Practice, MIT;
Mara Hancock, associate director, Learning Systems and Multimedia Services,
Educational Technology Services, UC-Berkeley; Brad Wheeler, associate VP and
dean of Information Technology at Indiana University; and Kathy
Christoph, assistant vice chancellor, Academic Affairs, University of
Wisconsin-Madison.
Victor Edmonds: This is a dream panel—an all-star team of leaders in
open source course management systems. Today, we’ll pose some questions
that are probably on your minds, too, as you ponder whether open source CMS
is right for your campus. Let’s poll the audience—do you see open
source CMS in your future, say, in two years? Our response system shows that
48 percent say they will be continuing with a commercial product, 13 percent
adopting Sakai, and 19 percent saying they will wait and see. Panel, should
we close down Sakai? How do you react to these numbers?
Brad Wheeler: I’m not surprised. Many people we talk to are waiting to
see if it’s a realistic thing. As far as Sakai g'es, the public release
was five days ago [July 2004], so it seems, since we are six months into a 24-month
project, waiting to see is reasonable.
Mara Hancock: I’ll address the 48 percent staying with the commercial
product. In looking at some of the primary concerns around migration and change
management, I can see why this would be a big issue. One of the issues cited
in an ECAR report about the reason why people weren’t adopting course
management systems to begin with, was the fear that the systems were going to
be changed on them continually. Knowing that you’ve told your faculty
you are going to be going with something, staying with that is kind of an honorable
thing right now, so people are trying to stick with that.
Phil Long: I’ll offer a different take on the 48 percent, namely, to
remind people that one of the critical goals of the open source movement right
now is to offer choice. The nature of what commercial products will be in two
years, if Sakai has the influence that we hope it will, is that there will be
a lot of adoption by the commercial vendors of some of the architecture, design,
and interface definitions and the like that are going to be represented in Sakai
as a reference model. So, I’m not at all surprised; in fact, I wouldn’t
know in two years what the landscape of commercial products is going to be like.
My hope is that it will be itself a much more diverse environment, with strong
influences from the work that Sakai is doing.
Charles Kerns: I feel the same way. I think that the CMS has become part of
the basic infrastructure. Most people have to be conservative. You have to make
sure that you don’t lose any faculty data, ever. And you have to think
about the feature set that you now have, and which of your constituents use
different features—you do a kind of gap analysis. Also, you have to think
about the user interface: do we have some people sort of married to their first
UI, the way we did with certain word processing programs? I don’t think
that’s a student problem, but I think it’s that “last 10 percent
over the fence” problem you have when you make a change. The other concern
is the opportunity problem: We have a whole set of new tools coming that open
source offers us, a new marketplace for tools, and we are really going to have
to think in terms of policy about adoption in a different way than we have in
the past. So, I think that everybody needs to be conservative in thinking about
maintaining their base—they want to be sure that Sakai has that base.
Edmonds: Kathy, you at the University of Wisconsin had to make a decision not
long ago about adopting a new course management system, going in a new direction.
How d'es this all look from that point of view now?
Kathy Christoph: The University of Wisconsin system made a decision to move
from two commercial products, to one product that is different from those two.
Talk about the pain of migration… I think there are two factors, when
you consider 48 percent of our audience today saying that they will stay with
their commercial product: One is, two years is not that far out—it actually
takes about that much time to decide what your goals are and to put your processes
in place even to select a new direction. Secondly, that migration is extremely
painful, so it’s a big decision to move. Plus, at this point [July 2004]
we don’t even know what Sakai d'es. Five days ago [was the public release],
so how much experience could we have?
Kerns: We’re surprised that 13 percent of our audience say that they
are going to adopt Sakai; we’ve just released it and we don’t know
what the feature set is going to be on 2.0. It’s an amazing amount of
trust in the team, which makes me very excited that people are looking to us
for that product.
Hancock: One thing to note is that the percentage of institutions continuing
to grow in-house course management systems has gone down dramatically. And probably,
if I can make an assumption, they have moved over to either “adopt Sakai”
or “wait and see.” So, I think that if you take the “adopt
Sakai” and “wait and see,” and put those together, it’s
actually quite an impressive number to rival the 48 percent.
Wheeler: The parallel there would be the commercial marketplace—we all
saw it consolidate to largely a duopoly with a few other credible challengers
around, and so now the same thing is going on in the home-grown market, as these
things come together.
Edmonds: What’s the number one value of any CMS?
Kerns: If you look at usage among our faculty, its biggest use is delivering
information or materials and documents to students. But I think that everyone
believes that that’s not the value of the product. It d'es help faculty,
giving them more time, but we used to call this the wheelbarrow problem. I think
you have to solve the wheelbarrow problem, because people expect that sort of
low-level stuff. But, the value is when you can move beyond that and really
use it for teaching and learning.
Wheeler: The new frontier for improving teaching and learning with technology
is probably discipline-specific tools. It’s a sure thing to provide a
generic syllabus, receive homework in drop boxes, and do all those pedestrian
functions. Those are valuable efficiencies. On the other hand, the drill-and-practice
tool that generates unique sets of math problems so that students can practice
and learn and discern what they are missing with math, is probably the real
value in learning math. Or, consider the tool that provides all sorts of videos
of different kinds of dance, or a game about the periodic table of the elements
for learning chemistry. Discipline-specific innovation is probably the next
frontier.
Certainly, our experience has been that you can ignite faculty innovation around
that by buying off time, through grants, and passing out the cookies, so faculty
and their graduate students will do wonderful things. But what they do is completely
unsustainable, from a technology basis, and these things can’t be shared.
Even if someone writes the greatest physics-tutoring tool, we can’t share
it with another university for a variety of reasons. So, to Cliff Lynch’s
point [in his keynote, July 19, 2004, excerpted on page 8], I think this flexible
suite of tools—where faculty can write things, and focus on topics that
extend learning in their discipline, or use the CMS to support their research
or scholarly output (after all, we call Sakai a “collaboration and learning
environment”) solving this core problem in ways that are economically
viable, and having he hooks to let people innovate and move their tools around
and share them—that’s probably where the next big wave of value
is.
Christoph: I don’t see that the current course management systems now
offer a flexible suite of tools for faculty. I think that’s what we’re
all hoping for as the number one value. One of the ideas behind open source
is that there will be many tools available, and we can choose the ones we want.
Long: By having a suite of tools, and allowing individual choice among faculty
to pick the ones they want and not the others, in some sense you promote what
any good technology evolution d'es—in that you make the technology that’s
underneath this, in some sense disappear. And you get to focus on the problems
of the discipline in ways that enhance the learning of that discipline. The
extent to which we can, through the thoughtful engineering of an environment
that’s modular and flexible, destroy the notion of a monolithic tool that’s
providing all of this, we’ll be doing all of ourselves a favor.
Edmonds: Twenty-one percent of our audience said they think one value of open
source CMS is saving money. Panel?
Long: First of all, I’m very sorry that so many of you think that’s
a likelihood, because you’ll be sadly mistaken. I guess the point that
is salient here is that it is less of an issue of saving money, because in the
end, I don’t think there is a savings to be had. I think it is really
where in the investment continuum you’re going to be putting your money;
whether you’re going to be putting it up front in license fees, and annual
fixed costs for renewal and code updates and things like that, along with a
base of integration costs that are going to be ongoing at some level, for the
foreseeable future… Or, whether you’re going to be putting the money
that you would have put in those licensing fees and the like into your staff,
into collaborations with others around your institution and colleagues’
institutions to do the development, or the shared development, or the co-development,
of the tools and things that are going to be helpful to you…
And you are still going to be doing the integration stuff, so that’s
not going to go away. But, you’ll be doing integration by looking at an
API that you can see the other side of, as opposed to wondering what on earth
they were thinking when they were writing it. I think it’s not an issue
of cost savings; it’s an issue of where you think you can bank on the
best value for the placement of your dollars. In some sense, I think there is
a certain degree of a paradigm shift in what you think and what you expect out
of your staff, in terms of being able to deal with these kinds of things. There
is a development responsibility when you are building these things, and it is
different than release engineering. If your staff is composed primarily of top-quality
release engineers who are taking and customizing a product, as opposed to a
group more accustomed to doing development, there may be a shift in training
that’s necessary before you can consider this as an option or as something
you’d like to pursue.
Hancock: We found, in talking with our instructors, that they really do value
us paying attention to what their drivers are and what their needs are. So,
for an institution, and especially an organization that is not only in the business
of developing, but also supporting faculty in training and use of those tools,
it’s really important that people see that we are responding to their
needs, and that they see that we are developing tools that match their workflow.
That’s one of the challenges of a project like Sakai, where we start—not
so much on the framework side, but on the tools side—to synchronize around
those issues with other institutions. There’s likely to be some tension
around those requirements that we are all going to have to learn to work through.
But I think collaboration with our peers is one of the big reasons why UC-Berkeley
ended up going in this direction. Because it’s not just “nice”
to collaborate, and get along and share things; it really reflects some of the
key values in higher ed. I was amazed, coming from the corporate side, how open
people here were open in sharing their tools and experiences, and I think this
really matches that. But also being able to leverage our resources, for those
who don’t have a large amount of resources in the development side of
the house—especially for teaching and learning—this allows us to
actually start to be able to compete; to provide something for our faculty that’s
really valuable for them, that when we can’t make changes on a vendor
product, we can make changes on an open source product. And that’s not
just we who are affected; it may be the other 48 institutions that belong to
SEPP [Sakai Educational Partners Program]—and I anticipate that number
is going to continue to grow.
Kerns: Customization is really important. I’ve been developing custom-built
tools for departments and faculty for 20-some years. If you look at what’s
available now, and what’s transferred out of the initial location, I think
it’s about two out of nearly 40 that I’ve worked on. So, we’ve
built things, customized for our group, but then it’s never shared, and
because it’s never shared there isn’t a sustainable community to
keep it going—and then it dies. This has really been the history of education
technology, not only on the practitioner side, but if you go to the research
area, there are numerous tools that would be very interesting to us that have
never gotten out of their model test sites. There were never communities that
could actually support them. I’m excited now that we have a bed to put
these tools in, which will link into an administrative system, and that we have
an organization that can build community. It’s customizing for our situation,
but it’s also customizing in a way that will let other people come in
and actually build community around a tool. There have been tools for problem-based
learning, and for case-based learning, and there have been specialty tools for
policy analysis, yet it’s very hard to sustain these. I’m looking
forward: How do we move beyond the community of developers into the community
of users?
Wheeler: The core challenges for IT in higher ed are building sustainable economics,
so we can base-fund high-level quality services, year after year—not with
hat in hand every year. Instead, I mean sustainable economics and sustainable
innovation. You can get the economics if you quit changing things, but if you
quit changing things in our business, you’re dead. So we’ve got
to find a way to pull both of those things together. At IU, we’ve reached
the clear and rational understanding that we could never innovate fast enough
to keep up with all the things, where this is going—especially in teaching
and learning and connecting to systems. What we needed was to find a mechanism
to work with like-minded partners who wanted to accomplish similar goals in
similar timelines.
More than anything, Sakai is a resource coordination mechanism.
We have a common architecture, common framework, and IU gets to leverage some
of the work that Berkeley has done. For us, that’s a big part of the long-term
value. This approach, community source, g'es after sustainable economics and
sustainable innovation. The collaboration is difficult and painful—and
valuable, when you learn how to do it.
Edmonds: Brad, could you tell us a little more about the term “community
source”?
Wheeler: I was at a gathering of our finance directors, and instead of being
interested in saving some money on licensing fees with open source, they were
horrified. So, we got to listening and talking with them some more, and what
we found out was, they had this vision of open source as funny-looking people
in strange parts of the world, uploading by dark of night changes to their mission-critical
software. So we thought it was useful to have a term that better describes what
we do, coming together in higher ed as consortia, with projects, with discipline,
with staff, with commitment. That dispelled a misperception of open source.
Edmonds: What’s the biggest worry about open source?
Long: I think there’s an issue that is often times associated with open
source, and that is, as wonderful as the community interaction and benefits
are, there is the question of will we burn out, or will our institutions stay
on point? Will we continue to do the work that needs to be done to keep this
alive? But the false dichotomy that is suggested here is that open source d'es
not have commercial support. One of the things that has been an important attribute
of what has gone on in the Sakai space, is that it is, in fact, extremely dependent
on commercial support and contracts. There are a tremendous number of vendors
interested in and potentially willing to take your money to be supporters of
integration, deployment, or development work that you either want to outsource,
or simply don’t want to worry about and you want a number to call. They
are there, and I suspect that they will be growing rapidly. In the Sakai space
there are already four vendors that are certified and identified as being available
to provide support for implementations, even though Sakai has been on the street
for all of five days.
Christoph: And I don’t think that we should ignore the fact that there
is a community of people ready to support open source also. I know when I first
started looking at open source, some of our library support people told me that
85 percent of the software currently underlying our library systems is open
source. And they swear that they get better support with that than with the
vendor-supplied products. We don’t have a support mechanism for Sakai
yet, but I think we have promise of having a good one.
Kerns: We also have the situation where fixes to the code can happen much faster.
You don’t have to wait for somebody to prioritize it, and it has a central
development group. So, besides getting the support of telling you what to do,
you also have the support of getting things fixed. I think that open source
has a better record of fixing things and promoting patches than the commercial
products do.
Christoph: Working with community source really
changes the dynamics of our organizations and what our staffs do and how we
manage. I’m very excited about that, because many of us have opportunities
to collaborate with other institutions, much like we are doing at a conference
like this, but in open source we are going to have many more of our staff also
working together. Our staff know the needs of the faculty, and they will be
able to work with other institutions daily, more than they ever have in the
past. When I look at my organization and the level of the people, the CIO, and
even occasionally our chancellor, having to deal with commercial companies to
get simple changes, I think, “What a way to spend your time!” I
would much rather go to my colleagues at the table and say, “We’ve
got this problem; do you have it too? Can we figure out a way to solve it?”
So I think that’s a very exciting future.
Pushing Technology into the Background
Services for Useful Collaborations
The “gee whiz” factor is finally gone from the transmission
and display of data bits, and it should be.
Today’s students can rightfully expect technology to serve their needs
effectively and unobtrusively. What are the collaborative tools and services
your institution should offer, and how can these operate ubiquitously in the
background—behind the walls and in the air? In the following excerpt from
a July 20 plenary panel at Syllabus2004, three panelists and their moderator
attack these questions. In the photo, from right to left: William H. Riffee
(moderator) associate provost for Distance, Continuing, and Executive Education,
University of Florida, with panelists Lois Brooks, director
of Academic Computing, Stanford University; William Griswold,
professor, Department of Computer Science and Engineering, University
of California-San Diego; and Lonnie Harvel, research scientist, Electrical
and Computer Engineering, Georgia Institute of Technology.
Bill Riffee: Today we’ll be talking about a number of technologies and
their impact on each of the campuses represented here. Let me begin by giving
you a short background of some of the things that have gone on at the University
of Florida. We have now about three thousand to four thousand people studying
for degrees online—not just taking courses—most of them at the master’s
level or professional doctoral level, and some in Ph.D. programs. We’ve
discovered that we can blend a lot of our technology into the background for
almost all of these students. The applications range from video streaming and
just downloading files, to collaborative software and facilitated sections where
they meet together as a cohort, physically. If you choose the right partners
and build the right systems, you can end up having technology that really and
truly blends into the background. Now we’ll hear from our panelists—
Lonnie Harvel: Among other things that I do at Georgia Tech, I’m the
associate director of the Arbutus Center for Distributed Engineering Education.
At the center, we are trying to find ways to bring together both the students
who are resident in the classroom and the students who are receiving courses—either
synchronously with geographically different locations, or asynchronously through
streaming media. We are trying to find the tools and technologies that blend
them all together. We are also trying to find the tools and technologies that
serve them both, instead of concentrating on them as separate groups. That’s
the reason we use the term “distributed” education. We are trying
to blend local and distance, and time them together in such a way that the factors
of time and geography don’t matter as much.
For a technology to actually move into the community in such a way that it’s
not in the foreground anymore, that technology has to be useful—believe
it or not, that’s the hard part. And ubiquitous—the technology has
to be there when the students need it, and it’s going to have to be general
enough. It also has to be sustainable.
It has to be useful. There is a quote I like from a recent article
in the Journal of Academe: “ ‘Build it and they will come’
may work for dead baseball players, but in general, it d'es not work for students.”
You actually have to take the time, energy, and effort to determine what are
the needs of your student community. What is the place that you want to embed
technology, and why? And how will that actually help the students? Just creating
technology as a nifty idea is no longer acceptable, and in many cases offends
the students. “I don’t need this—why are you asking me to
do it? How d'es this help me get a better grade? It d'esn’t increase my
understanding. I don’t care if you published it!”
So the first thing is to identify a real need. That means you may be falling
back on a lot of disciplines that may not be yours. You may have to look at
doing an ethnographic study. If you are a technologist, but you don’t
have someone from the learning sciences or education involved, your chances
of success are not too great. Likewise, if you are a learning sciences and education
person but you’re trying to do this without technologists involved, your
chances of success aren’t all that great. We have to pull these pieces
together.
It has to be ubiquitous. Especially when we’re talking about
technologies that we’re just now exploring, we have to remember to use
the technology to such an extent that we actually understand how it’s
being used. And we have to do it to the point where students begin to perceive
value. A lot of times, we just use them in one class and try to generalize over
multiple classes—but this makes me think our petri dishes are too small.
We need to ask ourselves as researchers, what is the critical mass necessary
to evaluate a particular technology?
We also have to ask, what is the payoff for students? We hear grumbling like,
“That was great, but now I have to attend another class that d'esn’t
use that tool. Why can’t I have it now?” In our case, the students
found the technology not as valuable if they only had it in one class—but
there was a massive jump in perceived value if the students had the technology
in two classes. That was a payoff for them. And once we got a technology to
the point where we captured an entire curriculum, the students loved it. The
problem was, we couldn’t sustain it.
It has to be sustainable. In our case, my joke was: It took two faculty
members, six graduate students, and four undergraduates per classroom to support
the technology. We are working to get to a level of scalability and supportability
that we haven’t reached yet. But WebCT and Blackboard have seen a lot
of the same kind of thing. The value grows, the more courses you use.
Enterprise-level systems are needed; they have to be stable, scalable, and
supportable. Commercialization is actually a really good thing, because most
of us are researchers and we don’t want to support the technologies after
we’ve already published our papers. We want somebody else to do that.
Commercialization will step in, usually after you have demonstrated some need.
William Griswold: Today I’m going to be talking about technology in the
classroom—not for distance learning. I noticed that participation in my
classrooms was dropping over time—I presumed, due to increasing class
size. At the same time, we were presented with a really great opportunity. UCSD
had deployed several hundred—now over a thousand—802.11b access
points on the campus.
We have virtually ubiquitous wireless coverage on the campus. And we received
a gift from HP of several hundred wireless PDAs, which we could give to our
students and do something interesting. Here was an opportunity to do something
about participation in the classroom.
My students and I introduced an application called ActiveClass. It’s
an application just for in-class communication, in particular, the participation
element in the lecture setting. Students could ask questions via their wireless
PDA, professors could post polls, and students could give feedback to the professor.
The idea was that there could be a silent and anonymous aggregated conversation,
a kind of back channel—an aggregated broadcast channel, not a one-to-one
instant messaging channel. We designed it to be click-driven, so that any text
that had to be entered, like asking a question, could then be clicked on to
interact with it. And we designed it for the small-form factor, for PDAs. It
was Web-based for ubiquity, and it used a stand-alone design, not integrated
with other technologies—it was just for in-class participation.
In order to assess the technology, we gave PDAs to more than 350 students in
three different classes, allowing them to fully incorporate the PDAs in their
lives outside the classroom as well. Because there was so much going on, we
used an ecological perspective, which didn’t dichotomize the technical,
social, or physical elements of the classroom—it’s analytically
neutral. It was able to look at everything that was going on and show the competitive
and cooperative forces that give rise to practice. This broadened our analysis
from just the students, to all of the stakeholders in the classroom.
One of the things we saw was that the professor took to calling ActiveClass
the “virtual student,” a very interesting turn of phrase. It had
the important quality of showing that this brand-new technology had become just
another student. So instead of moving from four to five pieces of classroom
technology, the change was from 150 students to 151—a small change and
not overwhelming. And it had the interesting quality of deflecting criticisms
from real, individual students, to the virtual student.
The anonymity fostered a more diverse mix of questions. This might have been
overwhelming in terms of quantity, except that the professor could prioritize
from a list of submitted questions. And the instructor was not alone in this—the
students could vote on the questions, moving them up in priority for a broad
appeal. The fitness gradient for questions had improved, because it was now
based on the questions themselves and on what all of the people thought of them.
The TAs were also able to participate in ways they couldn’t before, helping
out in a variety of ways—so everyone was a winner.
And there was much more going on than the study surrounding questioning. The
material layers change much more slowly than the practice layers or the software
layers. We tried and couldn’t even get a change made to a building that
hadn’t been built yet. Classrooms change at the speed of decades or even
centuries. Will all our classrooms still look the same in 100 years? Can we
really think about pushing technology to the background? I say, no, we have
to think in terms of bringing it solidly to the foreground. We saw that in order
to make ActiveClass succeed, with all of the great new wireless technology,
we had processes of negotiation and adoptation going on—in the foreground,
actively by all the participants. And if you really think about it, it is not
so much about foreground or background—it’s about fit. Do the spaces
and the tools that we construct fit the activity? It’s not that they actually
disappear, but they become so much a part of us that we are very comfortable
with them and forget that they were ever separate from us in the first place.
Lois Brooks: I love tools. I love blogs, Wikis, instant messaging… because
they allow people to do what they want to do without technology being the most
important thing going on. My version of background is that technology d'esn’t
slow you down, it lets you do what you want.
I’ll use a case study about a class we are working with now. At Stanford,
my focus is on deployment and support. So I’ll talk about what innovation
means from the back-of-the-house point of view; what it means to be transparent
and what we have to do to get there.
We have a new requirement in our first-year writing program we call the Program
in Writing and Rhetoric. This year, they are adding the requirement that the
students will need to do media—visual work—as part of their rhetoric.
They are creating still pictures and video as part of this, and also have an
oral requirement. The student will be working with digital for oral practice
and presentation.
What this means for us, from the IT shop point of view, is that we are continually
figuring things out. There are a lot of parts, both physical and information
space, that we need to work with. We need to have wired spaces for the students
and their laptops, equipment so they can shoot their video and do their audio,
and equipment so they can render and digitize. We need software available for
the students so they can do their work, scratch space for the media, and then
delivery and presentation space so their instructors can get to things.
And
of course, support g'es with all that. For every new pedagogical practice that
comes up, there’s a soup-to-nuts set of tasks that you have to do, and
if you can nail all those down and make them work well, in time, when people
need them, for the start of school, for the start of the class that day, then
technology becomes transparent and the purpose for using it moves to the front.
That’s not easy.
We also are doing the new technology and the new practice, we simultaneously
have the old things going on that we’ve always done. We have to keep the
old things going because we don’t change everything all at once. In the
case of our class, it means that we need computer clusters working with all
the new software that the students need, at the same time that we need to start
looking at licensing models for getting software out to the student desktops.
Imagine, when you are teaching, if no matter whether or not your students have
a computer, you know that they can get to the software they need for the class
when they need it, and do what they need to do. Wouldn’t that be wonderful?
That, to me, would be transparency.
The other thing we need to consider is that we are always looking at a continuum,
that we don’t change everything at once. In the case of our class, the
teaching space—the person-to-person interaction—happens at Wallenberg
Hall, a very high-tech new facility we have at Stanford that allows for, among
other things, students to work within teams and do peer editing on screens up
in front that they all share. In the continuum, then, we start looking at whether
we can pull some of these pieces of high-end technology out into the student
computing spaces—the clusters and the dorms—to allow students to
use them on their own time. To make that happen, we need to move from a high-touch
facility, with a lot of support, into a pretty bulletproof space so that things
work at midnight or two in the morning when students are doing their work.
If we want something to work, we can’t change it, we have to nail it
down so that somebody can actually support the thing. And if we want to innovate,
it has to change. As soon as we lock something down and say, “It’s
going to look just like this” it’s obsolete, and somebody will want
to change it in their classroom. There is a tension between innovation and supportability.
When we hit that sweet spot between them, we’ve done our jobs well. Our
faculty and students have an expectation that when we roll technology out to
them, it will work. The tolerance for downtime is fairly low. If you lose the
first half of a class trying to make the projector work, for example, it’s
all over.
So what do we need to do to make this happen? First of all, we need really
smart staff. The challenge for us, as the people who need to make this all happen,
is that we need to be one step ahead of the faculty and students if possible,
to understand the technology and how to support it and make it work. That’s
one of the keys to hitting that sweet spot. The other key is to have a lot of
these wonderful little technologies—blogs, IMs, and so on—available
for people so that they can mix and match as they choose and create a custom
classroom and teaching environment out of tools that we know how to support
and use. So, we start the process of allowing people to enter the technology
that exists in ways that are unique to them.
Finally, security—this is so difficult and so important. For security
to work, it means that it has to be usable. People have to be able to secure
things without a lot of hoops that they have to go through. Who you are and
what context you are in—are you in a class and can you see those things?
Are you in a class working with ad hoc peer group, and you want just your peer
group to see what you are doing, or your oral tutor, but not your professor?
Then on the day you choose, you say, “Now my professor may see this, because
my work is ready,” or, “My advisor can see this work, too.”
How do you make the security structure work in such a way, that as the students
move through their learning in the classroom, with the faculty, or with their
own groups, it works seamlessly for them? That’s transparent technology.
It’s not something that I think any of us have achieved in the way we
really want to.
