2009-08-05 interview with Tom Lewis

2009-08-05 - Phone interview with Tom Lewis, U. Washington

The Catalyst team is preparing to launch a new organizational approach for their tool suite. The new version is in QA and set for release at the beginning of September. Here's a preview.

Catalyst roles have been developed and managed in a tool-specific manner. Of the roles currently found across the web tool set, they've found that people tend to only use three: "Owner" (with all rights), "Assistant" or "Collaborator" or "Administrator" (with some varying intermediate rights and duties), and "Participant" (the lowest level; more or less what some other suites call "Viewer", although as Tom pointed out that name implies "lurking"). They're now trying to eliminate the less used sets, although that means the interpretation of an "Assistant"'s permissions may not always be intuitively obvious in a given tool. The GoPost discussion board requires a fourth role, "Moderator," described here. The WebQ tool went a little overboard.

Their current Group Manager is stable and popular. Currently it's restricted to two "namespaces": groups that I've created, or class lists for courses that I teach. There's no concept of role within the Group Manager (although class lists do apparently include the ability to discriminate between Instructors of Record and Students). Instead, groups are assigned roles as needed when managing access to a tool instance or workspace. I'll attach some screenshots.

The next version of the Group Manager is expected to support "Shared Groups" (a group created and managed by a user within Catalyst, but visible and usable by other Catalyst users). There's still no pressing need for hierarchies, though. There will also be integration with other types of "enterprise groups" delivered via LDAP. They'll leverage an existing authorization product called Astra since it's already in place. A nice plus is that Astra also takes care of deciding what Astra-managed data the current user can see. Astra includes limited support for hierarchical authorization. It lets clients use a combination of "privilege", "role", "action", "spanOfControl", and "qualifier" strings in decision-making. Here's an overview. A Powerpoint file at EduCause mention "roles" as particularly difficult to define or to use for sharing authorizations across contexts. To begin with, the Catalyst team is particularly interested in the delegation use case (e.g., department staff can set up workspaces for instructors of record).

A single person might have multiple Catalyst user IDs and use them in different contexts. But class list access only comes when authenticated by an official university NetID. For that reason they've added the ability to manage and switch between identities from the NetID account.

Memberships of each Workspace and each Tool instance are managed separately. There's no access inheritance or hierarchy. To put it another way, I manage the memberships and roles of a discussion board separately from the memberships and permissions of a workspace that includes a link to the discussion board. (Seems like this would make a realistic "Preview" difficult, since what I see might not match what any single workspace participant could see.) When they tried to work out good default workspace templates and role mappings, they didn't find enough commonality to make the effort worthwhile. Catalyst users tend to experiment with adding one tool at a time anyway.

September is when the Catalyst research and design team will really start to focus on all this. Tom likes the idea of a larger meeting for our projects. We agreed that whoever first gets to the point of thinking the time is right will get in touch with the other team.