Campus Collaborative Tools Strategy, First Draft: Please comment
March 27th, 2008 by Ian Crew[Edit: A draft of the findings based on this strategy is now available. Comments continue to be greatly appreciated.]
The Office of the CIO and Information Services and Technology are working with the UC Berkeley community to develop a campus strategy on how to use technology to best support collaborative work on campus, now and in the future.
You have an opportunity to shape this strategy and hence the future of collaborative technology used on campus. Today, we are pleased to release for your review the first draft of three sections of the upcoming Campus Collaborative Tools Strategy document.
We are intentionally releasing these first three sections of this strategy document at an early stage to elicit comments, feedback, and guidance from the campus community. We believe only through that method can we accurately represent the many collaborative practices and perspectives on the Berkeley campus. We would greatly appreciate any guidance, perspectives, corrections, or suggestions. We’re particularly looking for more guidance around the needs for collaborative technologies in research and teaching.
As of today, the final recommendations to be included in this strategy have not yet been written. We have made the decision to release these initial findings before the recommendations, in order to ensure that the recommendations reflect your feedback, and that of many others on campus, on this early stage draft of the document.
For more information
For more detailed information about this project, please see section II of the strategy document, “Introduction & Goals of the Strategy.”
If you have any questions, please contact Ian Crew, icrew@berkeley.edu.
Read the strategy
Section II-Introduction & Goals of the Strategy
Section III-Definition of Collaborative Tools for the purposes of this strategy
Section IV-Findings
Reviewer’s guide
We would greatly appreciate any response you might wish to offer. As you comment, you may wish to include:
- Your reactions to the data we’ve gathered
- Issues or data we’ve missed or omitted
- Your suggestions of additional issues the campus should consider
- An overview of the discussions or decisions taking place in your organization in these areas
- Your recommendations for strategic directions and next steps for the campus
We do realize that there is a great deal of information here. An outline of the first three sections of the complete strategy document, released today for your review and comment, appears below. If your time is limited and you can only focus on a single section of these findings, please focus on section IV.C, starting on page 50 of that section.
- Introduction & Goals of the Strategy (PDF, 5 pages)
- Key Questions
- Background for this work
- Methodologies
- Definition of Collaborative Tools for the purposes of this strategy (PDF, 4 pages)
- What is “collaboration”?
- Why is collaboration important?
- What are “collaborative tools”?
- What types of collaborative tools are available?
- Findings (PDF, 74 pages. If you can only focus on a single section of these findings, please focus on section IV.C, starting on page 50.)
- What are the primary contexts of collaboration on the campus, and how do people use tools to facilitate them?
- What collaborative tools are campus IT providers currently providing or using?
- What are key campus needs?
- What are the services and service models being offered by external providers?
- What are the costs of campus services and alternative services?
- What are other peer institutions doing? Why?
- What are other policy, legal, etc. issues we need to be aware of?
After reviewing these sections, you may comment directly below, in the comments section of this blog post. We may include quotes from any comment posted below in the report. If you’d like to be acknowledged for any quotes from your comments, please include your name, title, and organization in your comments. If you wish to submit a comment that will not be shared beyond the project team, send it to Ian Crew at icrew@berkeley.edu.
The deadline for comments on this draft of the strategy document is Friday, April 11, 2008. The complete strategy document, including recommendations, will be released for another round of comments in late April.
March 28th, 2008 at 10:53 am
Proprietary software (Microsoft, et al) should be avoided on principle.
As a public research and teaching organization, the University should use and contribute to open-source software projects.
Briefly, the salient advantages are:
1. Faster development, so that shortcomings are fixed sooner.
2. More input into direction of development. (Including contributing the work ourselves!).
3. Congruence with the University’s widest public mission.
Thanks.
March 28th, 2008 at 2:51 pm
The research and analysis reflected in the draft is impressive. However, I’m puzzled by one significant omission: despite the fact that 7 of the 9 contexts for collaboration take place in administrative units as well as academic and student services ones, the list of users interviewed includes no one from an administrative unit. While IT staff from administrative units were interviewed about which tools they use, in the first set of interviewees you’ve missed a huge segment of staff who are engaged in “the work that takes place every day on the campus” — not just as providers of services, but as users just like MSOs or deans.
March 28th, 2008 at 3:23 pm
Kathleen:
Thanks for this. Yes, we are aware that we need to hear more voices from those units, and we’re continuing to work to make that happen.
We’d be interested in your perspective. From your point of view, what sort of things would we hear from you or your colleagues in VCA in regard to collaborative practices, tools, and needs? What have we missed?
March 30th, 2008 at 8:25 am
Great to see efforts here, below are my comments:
Below are a list of priorities in collaborative computing for research in EECS:
1) Non-UCB accounts - we collaborate with many people outside of
Berkeley, they need non-public, secure access to resources. The issue
here is that there is no easy way to charge them, so requiring a
Berkeley login will not work.
2) Branding - we need to be able to easily brand multi-institution
projects with non-berkeley.edu domains and yet still use local
resources.
3) Platform neutral applications, especially Mac support.
4) We require these applications, in order of preference:
- Non-public mailing lists with good searching - However, the email
needs to possibly come from non-berkeley addresses.
- Wikis with public and non-public access - again, non-berkeley domains
(Wikis are the biggest thing to hit us since Powerpoint.)
- Access to non-public SVN or CVS repositories
5) This features would be nice:
- Online, collaborative application sharing that works through firewalls
6) We don’t need discussion boards, no one has time to look at them.
Christopher Brooks (cxh at eecs berkeley edu) University of California
Chess Executive Director US Mail: 337 Cory Hall #1774
Programmer/Analyst Chess/Ptolemy/Trust Berkeley, CA 94720-1774
ph: 510.643.9841 fax:510.642.2718 (office: 400A Cory)
March 31st, 2008 at 5:50 pm
I agree with Kathleen Satz’ comment about the administrative and support staff who use the campus systems and create internal shadow systems to supplement record keeping in compliance with UC, state and federal policy. Currently, there are some units on campus who have implemented internal workflow sytems, ic., intranets that should be made available to other departments on campus to improve tranactional processing that is currently paper-based due to the requirement of “ink” signatures. Advertising and sharing “best practices” in collaboration could result in standardized interfaces to campus sytems. Moving toward electronic signatures, scanned documents and online forms processing will improve efficiencies, provide accurate tracking and record management at the department level. This is critical for auditing and as more processes require record management at the department level, the issues of security and encription of sensitive data needs addressing. Better communication among the administrative managers and support from IT for implementing integrated systems needs to be addressed.
April 1st, 2008 at 8:31 am
Good start and nice job! I enjoyed reading it.
I participated in a systemwide study (ITGC) of IT needs, focusing on areas where the UC campuses could better coordinate and cooperate. One of the major areas of study was collaboration. Please take into account the ITGC report, and more importantly the opportunities to share resources with other campuses, or make compatible choices, and the need to collaborate across UC campuses. In fact, a fairly painless way to get collaboration working across all universities is to start by getting it working across UC campuses. The report:
http://www.universityofcalifornia.edu/itgc/
While some areas of application are fairly mature, like word processing, others are very chaotic with new and better things coming along all the time. A recent example is Twine, a semantic web application that many may want to use, or Blist, an online database application that may be much better than Excel for many purposes. In these areas of rapid innovation I dont think the campus can make a choice for the users that will be lasting; in fact, making and trying to enforce choices will slow progress. Rather, I would urge you to focus on creating a framework into which new things could be introduced easily. For example, we need an identity management system that works across vendors, and a way of capturing and archiving content that works across many vendors and applications. This is an area where a set of OpenSocial style of standards are needed supporting the relationship of the academic community as a whole with a set of cooperating vendors. UCB, and especially UC as a whole would have enough clout to drive something like this.
A related trend is that collaborative applications are mostly free. Not mentioned, for example, is the ready availability of free file sharing and wiki solutions. This removes a big motivation for using local resources to provision and maintain applications. I think our local resources are, in general, better devoted to getting the framework established, getting a variety of things working together, and dealing with infrastructure issues like data security and identity management.
Minor comments:
Most faculty and students work from off campus a whole lot. The current VPN is not reliable enough or fast enough to provide an adequate solution. All applications need to work seamlessly off campus.
“Teaching/learning in classroom”. Most of the activity you discuss occurs outside the classroom, so the heading is misleading.
Google Docs: I have found their spreadsheet to work well, but the word processor is not ready for prime time. Maybe it will improve to the point of being useful, but right now it is too buggy and incomplete. Something like this that supported the special academic needs and was solid would be very powerful.
April 4th, 2008 at 9:27 am
I noticed the following on page 11:
“Email, attached documents, mailbox search: inefficient use of storage, redundant copies (which is the most recent one?), inaccessible by others, large attachments have problems in transit.”
By campus supported email, perhaps you are referring to CalMail. If so, how did you determine that this system uses storage inefficently?
April 4th, 2008 at 9:56 am
Michael:
To clarify–there are many different email systems supported by the campus, not just CalMail. We were consciously not singling out any one system, but rather talking about how email works in general. The comment about inefficiency of storage in email has two elements:
1) On most email systems, if I send an email with an attachment to 10 of my colleagues, that file gets duplicated 10 times to be put in each person’s mailbox. We know that some email systems work around this issue and store a single copy of the attachment for multiple mailboxes. I’m not sure if CalMail works that way or not. I do know that bSpace does do that with email sent through its lists (attachments are stored on the server, and a URL to the attachment is passed along to the client).
2) Even if only a single copy is stored on the server, a copy of the attachment is downloaded and stored on each recipient’s disk (which in turn often uses space on a backup server or tape). When a new version is sent out, a complete copy of this new version is then stored on all these people’s drives.
Contrast this with a solution where a single copy exists on a server someplace, and the people who are working on it can all have access to it. This can be accomplished through many technologies (FTP, SMB/CIFS, WebDAV, AFS, etc.), and is generally a more efficient use of storage space.
April 10th, 2008 at 2:23 pm
One thing that I’d like to see is a “Cal-wiki” shared space. I think that it could compliment what we’ve got going with CalShare and bSpace already.
Where I work, we’d would like to get some collaborative online documentation going on. We have access to blog space through our department, but a blog doesn’t meet all of our needs. We don’t have an intranet.
bSpace could serve some of our needs quite well, including our need for online staff procedure memos and manuals that all of the staff could create and keep current.
One other need that we have is a way to make our website a little more flexible and collaborative. We were considering adding a wiki to the mix of static HTML-based web pages that I develop for our unit. These documents would be available to the general public as well as the students and faculty that we server.
Ideally, we’d like to be able to customize the wiki skin so that it matches our basic website design in terms of looks and (possibly) navigation. It would be wonderful if a “Cal-wiki” space could be flexible enough to allow us to do this.
A co-worker and I have talked about setting up a server in our unit and installing wiki software on it. However, that would really be overkill — our needs simply aren’t great enough to justify a dedicated server, and we would need technical support.
Perhaps we could have a space available for UCB developers that makes a choice of wiki software available (including mediawiki). That way, any interested users could try the various packages in a testing area, and then settle on the software that they like best for their production work. Once they’ve done so, they can set up something on “Cal-wiki.”
August 13th, 2008 at 5:01 pm
While IT staff from administrative units were interviewed about which tools they use, in the first set of interviewees you’ve missed a huge segment of staff who are engaged in “the work that takes place every day on the campus.Maybe it will improve to the point of being useful, but right now it is too buggy and incomplete. Something like this that supported the special academic needs and was solid would be very powerful.