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.”

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.

“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?

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.

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)

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?

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.