This is a space for the Sakai community to share information about engaging faculty in the construction of the Sakai Collaborative Learning Environment. Please feel free to add your ideas, experiences with faculty, and suggestions based on what worked (or what didn't work) for you.
Why do we care about getting Faculty members involved?
What do we hope might be the result of involving Faculty more closely in Sakai? The following list attempts to gather the ideas from the original discussion list. Change it at your will...
- create tools which better meet the needs of Faculty, administrative staff and students
- foster the development of innovative tools which meet subject specific needs
- share best teaching practice across institution
- share new teaching ideas across insitutions - and see what doesn't work
- make it clear to Faculty that Sakai is designed to meet their needs
Thoughts and voices
This section is the result of a discussion that began in the Pedagogy Collab site on the difficulty of getting faculty input. It was suggested that getting faculty engaged would be easier if the basic Sakai toolset had fewer "faults". It migrated into a discussion about the quality of existing tools, the process of developing new tools and about how developer resources should be spent. Is it more important to refine existing tools than to develop new ones? Can both happen at the same time, given finite developer resources?
Many voices were heard, starting (I believe) with Patrick Masson.
Patrick Masson of SUNY:
So how do I foster faculty/instructional designer interest and participation? My thought was to get them involved in the pedagogy and user DG's. Let them see how the process benefits their needs with a say in the way these tools are developed. I guess this is why Michael Feldstein is such a pain in the butt not only here in Sakai, but in our office as well. We both see the key to the adoption of OSS (and thus potentially Sakai) as faculty interest, and if they are not participating then they will not be interested, then knowledgeable and then advocates.
I think there is tremendous value in exposing the issues, debates and lessons learned form other institutions. If faculty can see what is possible through deployments at other schools, find best practices in the use of Sakai tools, discover fixes to their needs and have a voice (a collaborative voice across institutions that they can see directs development), I believe they will be come greatly involved.
Harriet Truscott of Cambridge:
From my viewpoint, it seems that the vast majority of people involved in Sakai very much want to create a product that is supportive, easy to use and appropriate for the Faculty and students who will use it - and yet each time I sit down with my users to use Sakai, I become aware of glaring faults. For all our concern over usability, the preferences and views (spoken or unspoken) of the Faculty who use Sakai are often unanswered. I've been thinking for a while about why this might be so. Why are things which seem obvious to me never 'fixed' - and why haven't I noticed problems which seem obvious when others point them out to me?
Are we getting too familiar with our own tools - do we fail to see the obvious problems, alternative uses, and potential new use-cases? Do we ignore good suggestions from other Universities - or do we not give them a high priority? Or do we not share our good ideas with developers from other places - and if so, why not?
Is what's desirable for one University entirely inappropriate for another? Will we never be able to have an off-the-peg Sakai tool that really suits everyone? Should our aim be in fact to make tools which are genuinely flexible and configurable on a worksite-by-worksite basis?
I suspect a mixture of the two is probably the case.
But how do we go about improving the tools we have within the existing Sakai structures? Simply leaving plaintive requests in JIRA doesn't seem to work. Should we make more of a fuss on this pedagogy list about local changes we have made in response to Faculty demands, so that others know about them and ask that these local patches are made public? Should we hop over onto the Dev list to name and praise developers who have made those small but important usability changes? Should we pedagogy people look at more JIRA items, vote for them and comment? Should we leave comments on the individual Confluence tool pages? Should we contact tool developers directly?
Bill Crosbie at Rutgers:
...identify developers that agree with you that a particular tool needs improvement. These are the developers that will give you their heart and soul because they agree with you that it could be made better. And having an advocate in this regard is important.Then the faculty/users/developers work together with the chief architect to plot a forward path for the tool.
Bradley Wheeler of Indiana University:
While we've certainly got lots of work to do to improve and polish our general Sakai tools, I'd like to whole-heartedly agree with Bill that much of the next wave of value will come from tools that target more narrow disciplinary needs. In fact, this was one of the main reasons that IU chose to move from building our CMS/LMS alone to work with others. We knew we could never innovate fast enough as disciplinary tools became an essential part of effective instruction over time.
We saw lots of faculty teaching/learning innovation that had great efficacy for specific disciplinary tools often existed as an island and was difficult to share, support, and maintain for others. These tools for tutoring in Math, Nursing, or "The History of Rock and Roll" couldn't travel and our faculty could not easily receive similar innovations from their disciplinary colleagues at other institutions.
Like Bill, I am hopeful that we are moving closer to a Sakai Platform on which many of these narrower tools can be built to support particular learning objectives. We need many of our best to help improve many of the items mentioned on this list, but I'm also looking forward to this next wave of "micro-tools" too. They may have greater impact on real student learning than is possible for our general purpose tools.
Ruth Sabean at UCLA:
..why can we not open up, on the Sakai project website, an evaluation tool that lets anyone test the current version (as well as new tools under development) and offer feedback so that we can begin to fix the ease-of-use problems that are what we hear about frequently from faculty members and from students.
Another good strategy when working with faculty and students on interface development is to ask them for an example of an easy-to-use website. I often wonder why we keep re-inventing the simplest aspects of the interface when a great deal of research and stellar examples are available all around us to simply clone. Just ask them what really is easy to use and why.
Can we develop a way to recruit faculty and students to be ease-of-use advisors to new tools? old tools? wherever we're aware there are problems? student interns would be a great way to reach faculty at their own campus or other campuses.
Other thoughts: add a section to the Sakai website for faculty-faculty exchanges, sharing of information, tools, strategies, conversations, however they want to use it under the encouragement of the Pedagogy group and the Faculty Development person suggested in Michael's email.
Michael Feldstein at SUNY:
Fund a full-time advocacy position to do for faculty participation what Jim Farmer did for SEPP in its early stages. (I would nominate Jim forthis new role without a moment's hesitation.)
Recruit (and fund) Sakai fellows who are teachers.
Seek funding for pedagogy-oriented VLE research with teaching faculty as PIs.
Create Sakai-wide contests for design proposals for new discipline-oriented learning applications, and make participation in design by end-user faculty (and students!) a strong criterion.
When designing new tools, create a step in the process that is an inter-institutional call for faculty review. Have participating institutions recruit faculty members to review design documents and suggest enhancements.
Participate in a joint tool designing exercise (from end user and interoperability standards perspectives) with Moodle. Take one idea that everybody is hot to get (like a blog, for example) create a common wiki design space, and work through common goals. Aggressively recruit faculty from Sakai institutions to participate.
Joseph Hardin of University of Michigan:
We look for new practices, that can be embedded in or enabled by new tools, that are of high faculty, and in these cases department head and dean, interest and work on them. The two examples I'd give here are ePortfolio and GradTools. One, ePortfolio, is of great pedagogical interest to all audiences (deans, department heads, faculty, students) because it supports an emerging pedagogical model; it also rationalizes an extant model in places like med schools (big puller here at UM) and professional schools (big players here at UM, and often early adopters). The other, GradTools, just helps everyone, again across the spectrum of audiences, keep their work organized. Both have been funded by pushes (or pulls) from the bottom. Both are examples of OS working, and of faculty/student practices being supported. And both can bring along the rest of Sakai.
Luke Fernandez of Weber State University:
...in practice most faculty "just want it (the technology) to work." Rather than seeing themselves as potential producers of technology often faculty are reduced to the role of passive consumers who play little or no role in shaping the ends of university life as they are defined by technology acquisitions. Rather than viewing technology as a community they view technology as a mere commodity that isn't anything more than, (to paraphrase Edmund Burke), a salt and pepper shaker to be bought and sold in the marketplace.....I know we shake this apathy to some degree by getting faculty to reflect on the pedagogical potential that can be leveraged in a particular Sakai tool.....I witness this emerging interest especially in tools like OSP or the Wiki.....but can we engage them in any real sense on a civic and political level? Can we get them to take an abiding interest in interpreting Sakai technologies through the lens of social science? Or is that a pipe dream and a strategy that has little pay-off? Perhaps this isn't really a good way to try to engage faculty?
My guess, if my campus bears any resemblance to other campuses that use open source extensively or build their own systems, is that individual campuses, if not always Sakai proper, host vitalized and ongoing
conversations between faculty and developers. But how to take these local conversations and the local bridges that exist between developers and faculty and synergize these with Sakai?
One way to move in this direction (as a small addition to the exciting suggestions that have made on this thread so far) is to make it easier for non-J2EE developers to integrate Sakai with the non-J2EE technologies and cultures their campuses may be using. By integrating non-J2EE apps into Sakai, the Sakai software can continue to foster and support all of the vitalized developer-faculty conversations that happen on the local level through the catalyst of home-grown software.
We've seen progress here with the development of Sakai Web services which provide in-bound authentication through SakaiPortalLogin. But I'm wondering whether these integration protocols could be made even easier to use. For example as far as I know (and I may be blind to something in Sakai), it's still not a simple matter for J2EE-challenged developers to perform outbound session and navigational integration from Sakai to a homegrown app. We don't have an "outbound authentication tool" that an admin could configure and make available and that faculty could simply drop into their course to seamlessly integrate a part of their Sakai course with an external homegrown app. For those of you who use Luminus or WebCT the technology would be akin to CPIP or Powerlinks....but we could do one better then either of these by making it possible to frame an external tool within Sakai and enable session integration without forcing J2EE challenged programmers to do coding on the Sakai side.
This I think, would help move us more in the direction that Michael suggests in turning Sakai into a platform (see http://mfeldstein.com/index.php/weblog/comments/259/ ).
My apologies for suggesting a so-called "tech fix", obviously the way to foster better faculty-developer conversations depends on much more than technology alone. But a more "open system" (e.g. a system that was more open to non-J2EE developers) could foster greater possibilities for integration with localized solutions, Moodle, and the faculty-developer conversations that bubble-up around those solutions.