Jeremy Smith's blog

Entry Is Labelled

Top 3 Most Wanted Services From ITS: #1) Social Software

I was going to call this "groupware," but that tends to drudge up imagery of Exchange, Zimbra, Horde, etc. I am not talking about that kind of groupware. Think more like Facebook. An infrastructure that would allow University individuals to create groups... any group. And swap membership in and out.

That would take a lot of plumbing. A lot of middleware work to make happen because the infrastructure would need some seriously well-though-out APIs to make the information available to any and all systems.

But no one cares about middleware, the important part is the services built atop the middleware. The obvious first service is a web application that allows persons to create groups, join groups, leave groups, post messages to a forum for the group, post pictures to the group, etc. But it's not just for "social" groups like the group dedicated to the people who like the television show Scrubs. It can also be used for professional groups — the iTunes at Case group, the Identity Management Group, the Case Daily implementers group, etc. Pre-populated groups like "Spring 2006, ECES 131 group", Case Archery Club, Film Society, etc.

With open and available APIs, other services could leverage the group membership. Such as the hypothetical wiki farm i.e. being able to setup a wiki that was world-readable but only editable by the people in the iTunes@Case group or could only be accessed by people in the Identity Management Project group. Create blog entries that only people in your "Friends" group could see. Create blog entries that only people in the Identity Management Project group could see. Share photos that only people in your "Friends" group could see. Share files that only people in the iTunes@Case group could see.

The reason this gets my #1 most wanted ITS service is because it can raise the tide of many of the other offered services. But implementation of such a service is tricky because without well defined and open APIs, the number of services available to use it becomes limited thus the usefulness of the service quickly negates itself.

Comments

  1. gravatar

    I absolutely agree. I'm assessing the future direction of online services for alumni at Lehigh and social/professional networking software is #1.

    The "How" is the biggest problem to solve.

    The idea of stitching together many independent pieces is the ideal case, but man...what a challenge that will be. In our world, that would mean tying together Banner, some enterprise email system, library resources, the existing portal (or something better?), and of course new services to meet the current popular systems (Facebook being a great case, Flickr being another).

    If Facebook only had an API that universities could tap in to so we could mine the heck out of it for alumni relations and development purposes...which, in total, is just our own "higher-ed-flavored" CRM system...

    You're right on the money about such a system "rising the tide" of all other systems. Specifically in alumni relations the trend is towards leveraging those affinity relationships. Facebook is showing us just how varied "affinity" can be. I only wish we could tap in to it from the outside, not just from the inside.

  2. gravatar

    I'm skeptical about the trickiness you're claiming lies in the implemention. Is there some features of the service you're imagining but not telling us? My first reaction to Facebook was "I could make this in a weekend."

    Assuming the scope is just what you've defined above, I don't see where the trickiness of the API design is. Say you define a REST interface so people can interact with it programmatically - what complex things are you imagining them trying to do that would be hard to design into the API, or would be hindered by having only a REST interface, for example?

  3. gravatar

    The facebook portion is easy. The API that the facebook portion would work off of is more difficult.

    Try designing it. I've got 4 different sketches. None of them seem elegant.

  4. gravatar

    I still don't see how a group membership API would be hard to design. You said you've tried -- well what problems did you run into?

    This is why I think your post must be unclear about the scope of what you're talking about. Would a Facebook-like app built on top of the API use the API to store and manage all of its info, or just to take advantage of the group membership aspect? Same thing with the forum app, how would the posts to the forum be stored -- by the API, or by that particular application, using only the API for group membership?

  5. gravatar
    well what problems did you run into?

    Storing the data and representing it in a way that a multitude of services could access it.

    Would a Facebook-like app built on top of the API use the API to store and manage all of its info, or just to take advantage of the group membership aspect?

    Just the group membership access.

    how would the posts to the forum be stored -- by the API, or by that particular application, using only the API for group membership?

    The API is just for group membership. A forum application would do it's own thing, it would only query the grouping API to determine groupings.

  6. gravatar

    It seems to me that a group membership API could a really small number of basic operations, and still be effective:

    1. Create a group.
    2. Add a user to a group.
    3. Remove a user from a group.
    4. Check whether a user is in a specified group.
    5. Get a list of all members of a group.
    6. Get a list of all groups of which a user is a member.

    Even allowing for ACLs or something to restrict access to potentially sensitive data, it doesn't seem that difficult to me. In fact, it sounds a lot like something that could be handled by the LDAP service. The operations also seem really similar to the ones provided by Sympa... maybe there is a way to extend that database to be more generic? If extending an existing service won't work, then it seems that a fairly simple database design with a lightweight web-service shell around it would suffice.

    Obviously I'm missing some critical aspect that turns a seemingly easy problem into a difficult one ... what is it?

    The main difficulty I see is not technical, but institutional/political: for the service to be really valuable, someone has to pre-populate the system with interesting groups (like the per-course groups you alluded to). Is this what you see as the big difficulty in implementing the service?

  7. gravatar
    it sounds a lot like something that could be handled by the LDAP service.

    Yes it does. Use LDAP to store all of the groups. Use mod_auth_ldap to handle authz on the services.

    The operations also seem really similar to the ones provided by Sympa.

    Yes it does. Use Sympa to handle all of the groups. Sympa has a set of web services. You could build pages off of those web services to handle the group operations. You could develop a mod_authz_sympa to handle authorization at the Apache level.

    f extending an existing service won't work, then it seems that a fairly simple database design with a lightweight web-service shell around it would suffice.

    Yep, that would work, too. Develop a simple DB with a wrapper around it for operations. Integrate Sympa to it (instead of the other way around). Integrate LDAP to it (instead of the other way around). With the information in the DB being replicated out to LDAP, you can use mod_auth_ldap to do authz on Apache servers.

    That's 3 of my 4 sketches.

  8. gravatar
    someone has to pre-populate the system with interesting groups (like the per-course groups you alluded to). Is this what you see as the big difficulty in implementing the service?

    That is one difficulty. I mentioned the Student Data Rewrite project in that we will be including enrollment information in the data feed. So we will actually begin having that information and can provision a grouping system accordingly.

    I've had talks with USG people in the past. They control the group membership in to student organizations. They would be willing to replicate that information up to us (by writing into LDAP, maybe, or using whatever other grouping API we cook up).

    For the rest of the groups, you use whatever else to populate and manage them. Sympa... a web app... something else...

  9. gravatar
    I've had talks with USG people in the past. They control the group membership in to student organizations. They would be willing to replicate that information up to us (by writing into LDAP, maybe, or using whatever other grouping API we cook up).

    How about pulling the information from USG into the LDAP?

    http://usg.case.edu/funding/webservice.php

  10. gravatar

    Does your fourth scenario involve Shibboleth?
    (If so, then I must have psychic powers or something.)

    Anyway, since I didn't say it in my first post, this sounds really cool and useful; I hope you are able to implement something.

  11. gravatar

    In creating my own list this one didn't make the cut. I have trouble understanding what value a Case branded social software suite would add over facebook? Everyone at Case, students, faculty, and staff, can use facebook.

    The primary reason that facebook (or any social software) works is because everyone uses it. It seems to me that adding YASN [yet another social network] to mix only makes things more difficult for everyone.

    I agree that social software would be nice at Case and at all universities. My suggestion is that it is already here and we encourage the few students that haven't already signed up for facebook to do so.

  12. gravatar

    All social software isn't like Facebook. What is needed is a way for associations to to be made between individuals. Recording and showing how everybody is interconnected is social software. Once you have associations between people, you get to do all kinds of cool things.

    For example:


    • I only want my friends to read my blog post

    • I want a wiki only editable by people living in Tyler

    • I want a website only viewable by juniors who have been on co-op

    • I want a website viewable for people currently enrolled in MATH 304

    Case could deploy said social software as a middleware solution with a minimal front-end for people to create their own groups and add/delete people from these groups. It wouldn't be a facebook clone. There is no point in making a facebook clone. We just need associations.

  13. gravatar

    I agree with Gregory -- what would make this kind of social software useful is the ability to restrict readership of a blog post, or of access to pictures of students, or of access to a document to a selected group of users.

    Weatherhead currently uses ClassTrack software to give professors access to photos of students, and has made that software useful because you can put the photos into a seating chart, and then track participation using the chart... and it's all password protected. The problem is that very few professors use it, and undergraduates have to go have their picture taken again and sign a release before we can put that picture up for their classmates to see. If instead, all students signed a release when their ID photos were taken, and any student regardless of where they were enrolled would show up in a ClassTrack system, that would be really useful.

  14. gravatar

    Also, I do not know how to access information stored by Facebook.

Post a comment