Roles, permissions, and a few other tweaks

Hi Nathan

This is excellent work and just the sort of approach needed to give Sakai a clear, consistent and effective UI.

I noticed that the terms "Widgets" and "Tools" appear on some pages as though they are interchangeable. Whilst they might be construed as the same thing by many people, my opinion is that it is better to have just one term and to choose it early on. This avoids any potential confusion and avoids different terms creeping into any code, as it's easy for this to happen once all this first-rate stuff gets coded up!

Another thought I had is that it would be useful to collect and organise the screenshots into some sort of browseable structure, e.g.

Dashboard
        +- Add Widgets

Site Home
        +- Add Widgets
        |
        +- Edit Look & Feel
        |
        +- Site Settings
                       |
                       +- General
                       |
                       +- Members
                       |        |
                       |        +- Add Members
                       |
                       +- Import/Export

This would make it easy to find a particular screen, it would provide a good representation of the functional aspects of Sakai that are being developed, and it lists those aspects that have been covered so far. Just a thought =)

Nathan,

Based on past experience, it would be useful to break "Guest" access down into two use cases:

1) The user is not identifiable and should not be identified (i.e. anonymous). For example, this is useful for anonymous survey type activities.

2) Authenticated access; i.e. any user that can authenticate to the system and can be identified. This case is useful when you want to open access but still want to know who the individual was/is.

Thanks, L

Two things:

I note that in your video, you talk about "tools", but when you get into Look and Feel, they are referred to as pages. Sakai has always had a distinction between tools and site pages, though I admit that these are often confused. What do you call a view with two tools on it? Calling them tools in the site navigation view furthers this confusion, IMO.

Secondly, when you discussion roles and permissions, you have a button to create a new role for a site. Easy to say, but my understanding is that there is a fair bit of administrative work to actually create a role. I have some doubts that this could be easily done in software (thought I could be wrong).

• Mark Norton

This looks really good. I really like that permissions go down to the tool level; this is really something that NYU is hearing requests for.

Based on some of the other requests that we are hearing, I think it would be really useful if the roles broke out of the "course metaphor." If someone was using Sakai for project sites, or if they wanted to allow people to join their personal Workspaces these roles would not apply well. You could let roles be defined more as user groups, that have permission templates applied to them. This way a course site could have a default "student" user group and default ta user group, but within a research project site the user groups could be titled entirely differently, even though the permission terms would be the same. This might be useful in the sense that an instructor might want her students to have full control over a site. But she wants to be able to have them to be labeled as students, for the gradebook, etc.

Along these same lines, to be able to allow Sakai to grow into something more flexible it might useful to think about permissions in global systems terms as well as site specific terms. For example, many faculty and students want to be able to upload resources, or create blogs and wikis and then share 1) just that resource with a select group of their peers; 2) with all students within a class; 3) with anyone within their department; or 4) maybe outside of Sakai entirely (e.g., a prospective employer might want to see a student's portfolio.

In this way it might be useful to think of permissions in terms like private, select, community (within the Sakai system), and public. And then applied to each of these visibility permission groups there would be options for read, write and delete permissions that could be turned on or off depending on the user group that it was being applied to. User groups might be shared across sites (and not); and everyone would be using the same access/permission metaphors regardless of the activities or type of site.