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.

comments powered by Disqus