Campus Collaborative Tools Strategy Draft: Please Comment
August 26th, 2008 by Ian CrewThe 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.
As we did with our findings, today we are releasing a draft of the collaborative tools strategy for review and comment.
We are distributing this strategy widely in draft form to elicit comments, feedback, and guidance from the campus and higher education communities. We believe only through that method can we develop a strategy that will support the creation of an environment where collaboration is easy and natural. We would greatly appreciate any guidance, perspectives, corrections, or suggestions. The development of the strategy to this point has been heavily dependent on the insight, comments and feedback we have from well over 200 people throughout the process. Our thanks to everyone who has taken the time to participate.
It is only through further input that we will be able to refine this into a strategy that is truly useful across campus.
Review the Strategy
Strategy, Draft 2 (PDF, 11 pages)
Several of the goals in this strategy are discussed in more detail in individual “Spotlight” documents. If you have particular interest or expertise in those areas, we would also appreciate feedback on those documents.
Providing Feedback
After reviewing the draft strategy, 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.
September 3rd, 2008 at 2:29 pm
I had the chance to meet with Ian, Rick and Aron last Friday to give feedback in person. We were also joined by E. Bond Francisco as we were giving feedback based on our involvement with BPAWG. Our biggest recommendation was pulling out 2d and making it into its own goal (which would be #7).
2d. Develop our IT workforce to support these activities.
(See Spotlight: Service Blending IT Skills for a more detailed discussion of this goal.)
The campus will need to develop the skills of its IT workforce through training and
hiring practices, to become better able to create, supply, and support services based
around technologies that combine multiple data and service sources.
This is due to the fact that Kuali Student and many other areas on this campus will require more business analysts and the time to plan for that is now. Our two cents!
September 10th, 2008 at 3:50 pm
Sharing intellectual property in a federated environment will need encryption for privacy, digital signatures for non-reputability, and security assertions that can be applied in different security realms. Under a single sign-on system an authorization token and role assertions are used to grant limited access to outside users. A message or document routed to different organizations may need element level security to protect parts of messages and documents not all recipients are authorized for. Different users would be able to read elements of a message intended for them but not what they are unauthorized to see.
September 11th, 2008 at 8:42 am
Thank you for incorporating administrative activities. The use of collaborative tools in administrative work can significantly improve support for the academic and research missions; however, administrative staff are not always expert in the selection and use of such tools, so including these needs in the strategy is welcome. I am also pleased to see Goal 5; staff are often reduced to creating our own informal communities of practice, but the campus could benefit from some level of central coordination and support for user communities.
September 11th, 2008 at 10:01 am
* If our collaborative strategy is based on the idea that we will
somehow prohibit people from using highly productive and
cheaply available tools (Gmail, Google Docs, etc., cheap wifi)
that don’t meet security goals, how successful will this
strategy be? especially if campus-bred alternatives impact
unit budget constraints and are less effective?
* Have we talked to Google and other providers to see if a more
secure arrangement can be made for using their tools? Berkeley
is big, and UC is huge – they will talk to us. As these tools
become more convenient – and free (ad-supported) – we see
people transferring their campus email addresses to, say, a
Gmail account with auto-forward of their Berkeley account -
because very few people can live with a 256-mbyte IMAP account
in the era of 160-gig PC drives.
* How secure is data via authentication? when much restricted
data is provided via email attachments? or from a source via
authentication, then downloaded to a home computer, laptop or
thumb drive? is there really a great difference in security
over a non-campus collaborative tool? how secure is
authenticated access to CalMail via Eudora, a non-supported
software tool that is still widely used on campus, compared to
say Gmail? in the era of phishing scams, is the weak link in
the security chain the tool, or the education of the user and
the inability to really enact ideal security practices when
alternative practices are far more available and productive?
September 11th, 2008 at 3:04 pm
All: Thank you for your comments. They are most helpful. Please keep them coming.
—–
Rob:
A few responses to your points are below. We will work on finding ways to make all this clearer in the final version of the strategy. If you noticed particular spots that were especially unclear, we’d love to hear about them.
1) With this strategy our goal is not to prohibit the use of any particular tool, but rather to encourage the use of a much wider variety of tools. This is really what the “Embrace the chaos” catch-phrase is all about. We need to stop thinking that we can control everything and dictate what is or is not used on campus, and shift to a mode where we support the development of communities of practice around the use of collaborative tools (regardless of whether they’re from an on-campus or off-campus provider).
The “Tier 7″ you see in strategic goal 3 is designed as a category for tools that are malicious, illegal, or harmful. We hope that there would be very few if any tools listed in this category. We’ll make that clearer in the final version.
2) At the same time, the university must find a way to reduce the risks and liabilities that inappropriately-handled data can impose. For example:
- If restricted data is stored inappropriately or transmitted over unsecured networks, that can impose huge financial costs (tens or hundreds of thousands of dollars) on the university, and can also lead to various personal consequences for anyone found responsible for that breach.
- Data stored with outside entities (be they commercial like Google or Amazon, or organizations or consortia) is often stored in data centers in other states or countries, making it subject to different disclosure, legal discovery, and privacy laws.
- Important data stored with an outside provider can be irretrievably lost if the provider shuts down or radically changes their service. (For example: What happens if the only copy of a picture of a new frog species was stored on a researcher’s Flickr account and Yahoo decides to shut down that service or modify the picture?)
- See section G (pages 69-73) of the document at http://dsblog.berkeley.edu/wp-content/uploads/2008/03/4_findings.pdf for a more in-depth discussion of these and other similar issues.
3) We feel that the only way to allow the use of a broader range of collaborative tools (#1, above) while minimizing the risk (#2), is to educate and guide the campus community’s decisions about which tools to use, with which data, to maximize productivity while minimizing risk and cost. Via strategic goals 3, 4, and 5, we hope to make the information necessary for members of our campus community to make prudent decisions in this area easily available.
Of course, we could be wrong–the reason we’re asking for feedback is to search for even better approaches for managing these issues. We would definitely appreciate any thoughts about alternative approaches.
4) We have indeed been talking with many outside vendors of collaborative tools (Microsoft, Google, Yahoo, and others) about these issues and this strategy document. We have invited them to comment on the draft strategy and participate in this discussion. We hope they will do so.
(As an aside: one interesting data point–we’re actually quite small when you talk about consumer-oriented services such as GMail, Yahoo Mail, and Hotmail. According to comScore, in December of 2007–the most recent month I could find data for easily–GMail had about 90 million active users, Hotmail had about 255 million, and Yahoo had about 256 million. In this case, the roughly 60,000 accounts from UCB or the 250,000 accounts from UC systemwide start to look pretty minimal. Still, the vendors we have talked to so far have been quite helpful and interested in our feedback.)
September 12th, 2008 at 4:18 pm
A couple of passages in the document show a bias towards applied research in the physical and biological sciences. I hope that you could lose this. It may be where collaboration is used and needed most currently, but that is because of the amount of resources and activity in those disciplines. “Humankind’s important challenges” definitely extend beyond those disciplines, and the need for collaboration does as well.
Also, either take out the mention of “credit crunch and housing price collapse” or make sure you bridge the gap between that and “most units… face flat or reduced funding for the next several years.”
Off topic, I hope the university looks hard at Zotero (http://www.zotero.org/) and the Dataverse Network Project (http://thedata.org/).
September 12th, 2008 at 4:50 pm
I’m especially encouraged by goal 2a, “Use open standards for data representation and transport.” Staff and faculty who collaborate should not need to be aware of the disparate technologies that connect them. The path to success includes attention to the user experience. Berkeley won’t be able to accomplish that without meeting goal 2d, “Develop our IT workforce to support these activities.” Skills needed include business analysis and interaction design.
As part of the Kuali Student project, I foresee a strong need for sharing calendar data. Mobile devices will increasingly be part of Berkeley life, adding another layer of varied technologies. Stanford recently replaced its Oracle Calendar implementation with open source Zimbra, with great success:
http://www.stanford.edu/dept/its/projects/integratedemailcalendar/benefits.html
http://www.zimbra.com/community/downloads.html
September 12th, 2008 at 6:41 pm
Ken:
Yes, you’re right that the “big problems” are a bit biased at this point. We agree. You’re not the first person to point that out (the others were sent privately), and we’ll definitely fix that.
Thanks for the feedback!
September 15th, 2008 at 12:42 pm
I think, for many campus departments, part of the lure of offsite tools is the fact that it’s free. In the face of budget issues, security concerns go out the backdoor when there are “free” collaboration tools. To me, having free tools, not just reduced costs, is very important.
September 16th, 2008 at 1:45 am
A great start, but I would like to see connections made between students and collaborative work more clearly outlined.
October 8th, 2008 at 11:56 am
In my work, I see a few issues that are hinderences.
The first issue is understanding who has what data. This might be helped by the University collecting and publishing data dictionaries.
The second issue is inconsistant object descriptions. By this, I mean, if you want a person’s name, or address, or a course name, what fields are you going to get? Is a person’s name stored as a single text field, or as 6 separate text fields? I work off campus with County data that has a very consistant structure to an address. Whereas, on campus, the enrollment and transcript db’s store course names differently.
My third issue is addressed in the Draft document – programmatic access to data. Our staff can randomly search and access data in the Registrar’s database, but programmatic access must be scheduled as a job, a text file created, and then ftp’d to my system. So all I can get is a snapshot, at a pre-scheduled time. I think Goal 2b is perfect.
I believe that consistancy in the the data structure (my 2nd issue) is an important foundation for collaboration.
October 14th, 2008 at 10:21 am
My experience as a full-time Linux desktop user is: The phone works very well.. Email works pretty well. VOIP & chat apps (Skype, Gizmo) can work ok if you get used to their quirks. Wikis & other non-synchronous apps can work reasonably well. Synchronous native apps (VNC) can work pretty well. Synchronous web apps don’t work very well, tho it may be that as a Linux user, I’ve missed the ones that do work well.
Collaboration is a buzzword being used to promote all kinds of applications that mostly do not seem to work. For example, our Medical Center spent quite a bit of $ to put Adobe’s Connect in widespread use. The people that have it do not use it, preferring to use Skype (which mostly does work) or the phone; I use both Skype and Gizmo for calls and conferencing (Gizmo has direct recording of conference calls which is useful).
‘Embracing the Chaos’ is one approach, but chaos by definition is hard to organize. there could be an ‘organizing’ attempt that attempts to do a running best effort identification of useful applications.
Most of the collab tools I’ve tried to use are web-based and tho one of the big advantages of web technologies is that they’re supposedly platform neutral, the horrible fact is that they are about as platform-specific as any application – the HTML generally works OK, but a codec for some multimedia format isn’t available for platform X (usally Linux). Or the version of Java is wrong, or it will reject you outright for having the wrong browser or browser version.
One large point would be to provide official support for only apps (web or native binary) that support open formats or those for which players exist on all platforms (ogg, theora, Real, etc).
Many people have mentioned wikis as a killer collab tool – well yes, as long as they’re configured correctly and the RSS or email notifications work the way they should. They are a ‘pull’ technology and therefore the you have to elect to go to them as opposed to the push technology of email. If you have a dedicated group of people who are determined to push a project, wikis can works really well. For distributed software development, they work well (see Trac). For other things, less so. More normal people tend to like listservs or Forums like phpBB which doesn’t have the perceived overhead and permanence of a wiki page. there is also the difficulty of setting up the infrastructure which is a hindrance to many. Campus support for a wiki infrastructure is one way to lower the activation energy of experimenting with such technologies. A campus server with Mediawiki, Trac, the MailMan listserv, phpBB, and Wordpress blogging sw and a host of other such collaboration technologies would be an interesting experiemnt to see which ones are used best. For example, UCI’s MailMan server currently hosts 480 lists (tho most of them are inactive or very low traffic) and a local forum that someone set up independently has grown out of control (tho others have withered – it very much depends on the audience and how strongly they feel about what is being discussed).
Email is still the killer information conduit. It is a well-understood format, there are great native applications for it, it can be digitally signed, and encrypted to the level that any university needs. The back end storage can be ugly, but it’s a technology that is understood. If it can be integrated into a context that other collab tools can be layered on, it can work very well.
I saw one comment about Zimbra (now part of Yahoo), which is a solution that I selected for a workgroup for its fairly good integration of a number of technologies. There is an Open Source version of it and it should be a development platform to consider exploiting. It supports wikis, file sharing, shared notebooks, email archiving and discovery. As such, it can be used for things such as electronic lab notebooks as it provides the timestamping, digital signatures, write-once archiving, and discovery (which is how I stumbled upon it). I’m not sure it’s still the best such app and I’ve had my share of problems with it, but it’s not a bad dev platform.
The problem I see with many of the collab tools mentioned (blist, twine, google apps, etc) is that when they work, they work … barely. Just about any native app works better than a web app. And they place the storage of the users’ digital property outside his ownership domain. The level of web app interactivity is changing for the better with better Javascipt/AJAX interfaces and faster JS engines, but it’s still a generally unpleasant interface.
While it has a number of advantages for other things, layering UC auth/auth on top of unpleasant interfaces would appear to drive users away from UC-provided resources into the chaos cloud where at least if the tool is minimally useful, it can be used by anyone. It may be unpleasant to have to remember yet another login/pass, but at least you can interact with the people you need to. A fair number of our most internet-aware researchers are going outside the university boundaries for such tools.
A better approach for the present is to STRONGLY encourage public API data and communication formats and let people use the native apps they want. When they need to interact, it’s been my experience that most DON’T interact with shared desktops, but by phone (and docs that have been shared beforehand), or chat-shared. The one shared desktop model that seems to work better than any commercial one I’ve tried (and I’ve tried a number of web-based ones) is simply VNC. It can support at least 10 remote connections, provides pixel-perfect viewing and not-bad 2D interactivity (viewing mostly static docs, not so good at lots of pixel movement).
I’ve gone on for far too long – forgive me.
harry