1. Site Home Page

Link available in the dashboard view of a site. The link itself brings you into
the first tab, the dropdown menu brings you into a particular section of the Site
Settings.

2. Site Settings - General

Note: A change to Site and possibly SiteService is required to allow the setting of Site Owner (site.getCreatedBy()), otherwise this would be 4 hours effort at worst, after talking to Ian we are
going to handle this using some hacking and cheating to avoid thawing kernel

ToDo :

Domain

Description

Work Estimate

Technical

Saving all of the data on the page

32 hours

Data Feed

Data Feed that allows updating a sites Site owner (createdBy), Site name (title), Site description (shortDescription,description), Status (published), Public/Private (pubView) and Default Role (joinerRole)

16 hours

Total: 32 hours (Incomplete est.)

1. Site Owner

We envision this to be someone who is responsable for the site. For now, this
will pop-up a lightbox screen which will allow you to pick someone from the
member list and make him the site owner. If there is no site owner, we pick someone
from the list of maintainers, if there is no maintainer, we pick the Sakai
Administrator (uses feed from above)

ToDo :

Domain

Description

Work Estimate

Feedback

Gather feedback from institutions to see whether this 1 owner approach would work

8 hours

Design

Design the lightbox that shows the list of users and lets you pick one

8 hours

Technical

Implementation

24 hours

Total: 30 hours

2. Site Id

The site id will be shown inside the url of the webpage. The site id cannot
be changed at this point anymore.

3. Member's Default Role

We rename this to: All new members become

3. Site Settings - Members

Note that currently getMembers() returns all user ids with no sorting or paging ability. This tends to be turned into a huge list of Participant or User or whatever is desired. Suggest sending all users for now and sorting in javascript OR implementing a sorta REST interface which is somewhat inefficient but can improve when the Sakai code improves (reduce the estimate if page/sort is deemed unimportant)
Notes: The last login is stored in a table and uses a listener, structure like so: UserId, Time, SiteRef
The SiteRef is null if it indicates the last login to the system, otherwise it is the last access to the site,
probably would require a set of observers to keep the table up to date.
The feed here would need to pull all memberships for the site and then include that total count in the data returned. It would also need to respond to the page and perpage get variables and respond to sort options as well.
This will be built into the existing membership feeds here: /direct/membership/describe
(code in the core-providers in EB)

ToDo :

Domain

Description

Work Estimate

Data Feed

Feed that gets the list of members for a site, including username, email, last login, role and status. Also make this feed pageable and sortable

16 hours

Total: 16

1. Select All vs Select All Visible

This is an attempt to not to make this page less to heavy to load. Select All
would select all of the records in the recordset (300 here), while Select All
Visible would only select the items visible on this page.

ToDo :

Domain

Description

Work Estimate

Technical

Implement this selection mechanism

8 hours

Total: 8 hours

2. Paging

Mechanism used to page through the members. This isn't the most elegant option
yet, and might need some redesigning.

ToDo :

Domain

Description

Work Estimate

Design

Look at the Fluid Pager and possible design

6 hours

Technical

Look at implementation of Fluid pager

24 hours

Total: 30 hours

3. Members

These member names are links to a profile page of that member. This will
be implemented to show a step up to the concept of social networking.

ToDo :

Domain

Description

Work Estimate

Design

Design this profile page

See comments

Technical

Implement

16 hours

Total: 16 hours

4. Emails

When you click on this, it will try to send an email (mailto-function)

5. Last login

Displays the date the user has logged in the last time on the system/visited the site.
There are a couple ways to get this but none are particularly efficient. It would be good to have a lastlogin stored on the user.
This would use the last login table from the feeds above. Access to the data should be simple since it would
just be a lookup of the membership based on the userId and siteRef.
/direct/membership/describe

ToDo :

Domain

Description

Work Estimate

Design

Look at whether we want to display last site visit or last system visit

See comments

Data Feed

Check scalibility and data availability of this last login field

4 hours

Total: 4 hours

6. Roles

List of available roles within the site
Feed would be simply to get the available roles and statuses OR set the role/status for a user in a site
Add this feed to the membership provider: /direct/membership/describe

ToDo :

Domain

Description

Work Estimate

Data Feed

Data feed that changes the role/status of user(s) inside a site

4 hours

Data Feed

Include the list of available roles in site feed

4 hours

Total: 8 hours

7. Status

Tells whether that user is currently active or inactive. If the user is inactive,
the previous fields grey out. If the user hasn't logged in yet, we still keep this
active/inactive field and the last login field would just say "Never".

ToDo :

Domain

Description

Work Estimate

Technical

Implementation

2 hours

Total: 2 hours

8. Update

This button will be removed, as saving will happen automatically after making a
new selection in the dropdownboxes.

ToDo :

Domain

Description

Work Estimate

Design

Design Feedback on auto-saving

4 hours

Total: 4 hours

9. Delete selected

This would remove the selected people from the site.
This works as described in the feed description page: /direct/membership/describe

ToDo :

Domain

Description

Work Estimate

Note

Design

Design confirmation lightbox that shows up when Delete button is being pressed

2 hours

Technical

Implementation

4 hours

Data Feed

Feed that allows to remove members from a site

2 hours

/direct/membership/describe

Total: 8 hours

10. Select a Command

This list will activate once a user is selected, and will allow you to bulk update
the list of selected users (e.g. change status to active, change status to inactive, change role to x)
The bulk update feed should already be completed in membership provider. /direct/membership/describe

ToDo :

Domain

Description

Work Estimate

Design

Come up with the actual commands

3 hours

done

Technical

Implementation

12 hours

Total: 12 hours

11. Add Members

This button activates the Add Members lightbox (see 3.4).

4. Site Settings - Members - Add Members

1. New Members

For now, we will ask for user email addresses only, as this is most likely
easily rememberable for people. This does need investigation.
We might also add some kind of search function to this screen
(e.g. search for people with a first name and last name, ...).
NOTE: review the add participants helper code/work as this has already solved many of the technical issues related to lookup/resolution of usersWARNING: We cannot go forward with this until there are clearer requirements about how the users should be listed (by username, lastname, id order, ?) and looked up (by email, username, etc., ?) and even displayed (displayname only?, gmail style?, ?)

ToDo :

Domain

Description

Work Estimate

Feedback

Get feedback on the "add based on an email address" - approach

8 hours

Design

Design the search screen/helper

*36 hours

Technical

Get feedback on how well this search function would work combined with LDAP directories

4 hours

Total: 12 hours (Incomplete est.)

*These hours not included in totals. I recommend we stick with the email approach for now using the simple text box with line break as designed.

2. Default Role

This will default to the Default Role set in 3.2.

3. Optional Message

This optional message will be inserted into the invitation email that will
be send.NOTE: How should this message be handled in the feed though?

ToDo :

Domain

Description

Work Estimate

Technical

Implement optional message concept

Total: ? (Incomplete est.)

4. Send invitation

This will add the selected users to the site, give them the selected role
and send out an invitation email.
May want to allow adding each user with a different role rather than doing all users with the same role?
Look at the new add participants stuff for tips.NOTE: How should we handle the configuration of the email message?
This would be part of the memberships feed but would include an extra option for sending the email.
/direct/memberships/describe

ToDo :

Domain

Description

Work Estimate

Design

Design confirmation message + feedback message

4 hours

Technical

Implementation

16 hours

Data Feed

Feed that adds users to a site with a specified role and sends out an email invitation with a custom email message

16 hours

Total: 20 hours (Incomplete est.)

5. Site Settings - Roles & Permissions - Modify Permissions

As most of this is controlled by the super admin in the Realms tool, we will
drop these screens for now. We might want to change the second screen so that it
becomes an aggregate view of all permissions for tools used within the site.

ToDo :

Domain

Description

Work Estimate

Design

Redesign page for aggregate tool permission view

16 hours

Technical

Investigate whether such an aggregated view can be achieved

Technical

Implement a set of widget permissions that control controlling widget layouts, changing settings on widgets, ...

32 hours

Total: 48 hours (Incomplete est.)

6. Site Settings - Import/Export

For now, we will remove the Copy My Sites and Site Templates tabs.

1. Red areas

All of these fields will be removed from the screen. The screen will allow
you to import a site's "structure" (tools - dashboard layout - settings),
and export the structure of the current site too.

ToDo :

Domain

Description

Work Estimate

Design

Re-design screen

4 hours

Feedback

Request feedback from the WG looking at archiving

6 hours

Technical

Investigate how export and import happens nowadays

Total: 10 hours (Incomplete est.)

2. Site Backup & More

We will rename this tab to Admin, and it should contain some explanatory
text of what the screen does

Personally, I think it should be the last time the user signed into / visited the site. I say "signed into" a site because I envision that users can come directly to a site's gateway/login page without going to the general gateway page. This would let them skip going to their dashboard first... and just log into the site.

This would be helped by the direct URLs we discussed as part of the unique site ID.

1. "Site ID" - These screens describe changes to an existing site rather than a site that's in the process of being created, and Sakai 2.* doesn't allow changing an existing site's UID. If the user story being targeted is a friendlier URL, would it be achievable via a site alias feature?

3. "All new members become" (AKA "Member's Default Role" - If I understand this feature correctly, it only makes sense if the site is "public". If the site is "private", the option should be disabled or removed.

Nico's OSP / Content Authoring demo had the "Site Settings" link pop up a widget-ish lightbox, and the "Close and Return to..." link seems to go along with that, and so I started off taking that approach. On a closer look, though, I see that the "Members" tab itself can produce a pop-up div, which makes me suspect that navigation to a new URL is called for instead. I'll go ahead and switch to that approach.

Ray, the Site Settings lightbox that Nico added is a bit confusing because it's not formally part of the design, but rather something he is experimenting with. That link should bring the user to the "General" Site Settings tab. The rest of the tabs in Site Settings should behave as any tabs might be expected to... just a navigation bar.

One last (I think!) clarification on the "Site Settings - General" screen.

The Site Info tool in Sakai 2.* gives control over "Global Access - Display in public site list" ("site.isPubView()") and "Can be joined by anyone with authorization to log in" ("site.isJoinable()") as separate items. The "Role for people that join site" selection ("site.getJoinerRole()") only matters if the site is joinable. Site Info's default is to have a new site be publicly viewable but not be joinable.

Your screen mock-up here leaves out the "Can be joined" option. Unless told otherwise, I'll take that as meaning that you'd like to simplify the current process by making any publicly visible site joinable. This does mean, though, if a user goes to an existing site with then new "Site Settings" screen, clicks on the "Private" radio button, and then clicks on the "Public" radio button, they likely won't be returning the site to its previous state. I doubt that this is much of an issue, but I thought I'd better point it out just in case.

I see – glad I asked! I was mistaking "Current Status: Active / Inactive" as equivalent to Site Info's "Site Status: Publish Site" (site.isPublished), whereas it's actually a combination of site.isPublished and "Global Access: Private / Display" (site.isPubView). So we still have overloading, but since this combination matches the default behavior of Site Info, it's less likely to cause confusion in real life.

There are additional site access modes which aren't currently available in the UI but can be created through role permissions, viz. if you add the .auth and .anon roles to a site and grant site.visit permission, you can make the site visitable by (a) not-logged-in users and (b) logged-in users, who nevertheless aren't members of the site.

In that case, there should be a "Join this site" link somewhere so the users can choose to become members if they wish (and are logged in).

It's not what's described in 7.4.3. It's the ability to go directly to the site by URL and interact with the site the same way a site member would be able to, but without first joining it.

To configure sites like this in the current 2.x architecture also potentially requires adding 1 or 2 new roles to the site's realm (.auth and/or .anon) with the site.visit permission set, rather than just changing site options.

Decidedly non-trivial, yes, and it's probably worth pointing out that it's deeper considerations like this - and not a misunderstanding about your intent - that has in the past led me to think that portions of the designs to date have been somewhat more 2-ish than 3-ish.

Your comments refer to an investment dilemma that I understand and sympathize with. But I'm a firm believer in iteration and think these designs will lend well to that philosophy. IMO, no matter where we go from here (these 2-ish designs), the margin of throw-away will not be greater than 25% – keeping in mind that we'll want some backwards compatibility with legacy Sakai. But even if I'm wrong about that estimate, the implicit benefits of actually finishing something we started, as a team, will likely out-weight the explicit results. Albeit that last point has been harder to prove given the resistance to such a premise.

I also think that a progressive release plan makes more sense to consumers in the short-run (yourself included). Sure beats using 2.6 for the next n months (or more) while we get 3.0 designed and ultimately developed. Correct me if I'm wrong.

I fear you hear me saying things I don't intend. I mean only to encourage that 3-ish designs go further in challenging the assumptions of the current architecture, and this seems to me one good example of an area where those assumptions could be pressed. I make this point independently of questions of project management and resource.

Our preference locally has long been an Amazon model of public areas, forcing a login only when the user takes an action that requires that their identity be known, or otherwise "step behind the curtain." I think this could have a significant impact on the assumptions of the UI, but those assumptions should be reviewed.

I know we can worry about precise wording later, but with your new text I'm still not 100% sure if what you're calling Current Status is or is not equivalent to the current "Publish" checkbox (seen in Manage Access or when setting up the site), i.e. "Publishing your site makes it available to the site participants."

Mostly, I just want to confirm that "Current Status" allows for the use case of making it so that site participants can no longer (or not yet) access the site. (i.e. "unpublishing" in this sense means making the site "disappear" so it's no longer accessible even by those that are already participants...not just making it disappear from the public site list.)

Before moving on to the "Site Settings - Members" screen, I'd better jot a couple of notes on the not-completely-implemented "Site Owner" feature.

1. Sakai 2.6 and earlier doesn't have the concept of a Site Owner. Instead, it prompts for a "site contact name" and a "site contact email" and stores them as arbitrary text fields in the site properties table. Their default values are the name and email address (if any) of the user that created the site, but they could be set to anything. Two potential use cases that I know about are for an instructor to set up course-specific email aliases for smarter filtering, and for a project site to point at an email list of administrators. As with a lot of Sakai, though, I haven't seen any data comparing how many people take advantage of that opportunity to how many would prefer the simplicity of picking a member.

2. Since the current Sakai Kernel doesn't support a Site Owner, Aaron was asked to override the existing "Created By" site property. I'm doubtful about taking that approach in production, though, since who created a Sakai entity is pretty basic information which we might not want to throw away. Alternatively, we could add a "site-owner" user ID property to the same table that currently includes "contact-email" and "contact-name".

3. "For now, this will pop-up a lightbox screen which will allow you to pick someone from the member list..." Since a site can easily contain hundreds of members, this lightbox should include filtering, sorting, and paging.

The "Site Settings - Members" graphic shows an "Invited" status in the same column as the "Active"/"Inactive" select menus. It's not called out in the notes here, so just to clarify: There's no such thing as an "Invited" status in current-day Sakai. "Active" is a Boolean flag which means you're either in or out, so we're just implementing those two states on the pulldown menu.

Nathan/Nico, in "Site Settings - Members", should the software attempt to remember which rows have been checked after an update, or should we start fresh each time? (My guess would be the former, with the understanding that some or all of the previously checked memberships might have gone away. Similarly, I imagine we'd like to preserve the current page number and the current sorting state as much as possible.)

Ray, I'm not quite sure. I would be inclined, looking at other applications throughout the internet, to not remember the checkboxes on the previous pages and start with a fresh start every time. However, as I said, I'm not sure about this. I think I would be worth for Nathan to spend some thinking around the workflow of this "component".

Actually, I think we'll find it less troublesome if we choose the latter option. Some of this depends on the type of command, but in our case, I don't see a command that warrants keeping the selection active. Do you have an example of one that I'm not seeing?

Also, assuming I catch why you might be thinking the former, you could get fancy and try employing a Google-esque "undo" link once the action is performed.

As for sort order, just to be clear what you mean by "preserve", if the user is sorting all "Active" members, then performs an update on some to change their status to "Inactive", then those would be dropped to the relative bottom of the sort.

Cool, I'm fine with not remembering previously selected items after an update – less code == less work & fewer bugs.

As for sort order, just to be clear what you mean by "preserve", if the user is sorting all "Active" members, then performs an update on some to change their status to "Inactive", then those would be dropped to the relative bottom of the sort.

If you try that currently, you'll see that your sorting selection is lost when the update refreshes the table. In other words, any successful update returns the table to its initial state.

It does it that way now because my default way to keep development going when an open question might block me is to pick the easiest choice.

I wanted to piggyback a complete data refresh on updates so as to help keep the client side up to date with server-side changes. Unfortunately, it turns out that the official way to refresh data in a Yahoo DataTable has the side-effect of resetting sort choices. Functionally speaking, I don't see why this would be required, so my guess is that it somehow made life easier for the component coders. Anyway, I'll spend a little more time researching the question and see where I get.

"Site Settings - Members - Add Members" : Shouldn't the "Default Role for These Members" label be "Role for These Members", since the current workflow (unlike the legacy Site Info workflow) does not include an extra page in which the default might be overridden on a member by member basis?

To me, at any rate, calling something a "Default" implies I'll have a chance to override it if I want. However, in this workflow there's no extra step that gives me such a chance – all new members simply receive the role I've selected. Since "Default" doesn't seem to add any meaning to the label, I'm guessing that leaving it out would be clearer. But obviously it's no big deal to leave it in and see how the usability testing goes.

I'll voice my opinion (but Nathan should give the final word):
It's better to leave it off unless we believe it does add meaning. (User-testing is less likely to show that something is extraneous than that something is missing.)
Also, I'd add that "Default" as we're using it is actually a computer science term, and still has other meanings (e.g. related to failure, and finances) in the world. If we think (or find thru testing) that an adjective is required to let them know that somewhere down the line they can change the role, "Initial" might be better.

"Site Settings - Members - Add Members" : When the user makes a typo (or some other mistake) and specifies a user ID or email that does not actually exist in the system, how should the error be handled?

2.6 Site Info treats a list of new member as an all-or-nothing thing. It notifies the user of the unknown ID or email and waits for further instructions.

Conversely, we could ask the server to add the people it recognizes and return an error message about the ones it doesn't.

Deciding between these two probably also has some impact on where you'd like the error notification to show up: on the lightbox, or on the main page after the lightbox has disappeared.

Another error case reported by Site Info: "The following participants are already members of this site and can not be re-added: 'jane'"

The question remains whether we should continue to treat "Add Members" as an all-or-nothing operation in which any error keeps the site as it is and adds a message to the "Add Members" lightbox, or whether to allow partial successes in which the lightbox is dismissed and a message is added to the main "Members" screen.

One use case here is that someone will cut & paste a long list of usernames / email addresses (say several hundred). In general the person doing so wants to know that some of the users could not be added successfully, but they don't want to go and have to remove each failure case from the source list by hand before being able to add them. So a "soft fail" here is better, i.e. warn about the exceptions rather than preventing the whole operation.

Squeak I'll throw in the observation that sometimes you don't want partial success because you want to go fix the list and try again. It can sometimes be harder (or sometimes not the way someone thinks to do it) to generate a new list that only contains the fixed names. It can also be confusing if you fix the list and then submit the whole list again, but then since some were already created, you now have a new bunch of names triggering alerts because the accounts already exist. You might not have a good deal of confidence that buried in the errors aren't some other problems in addition to duplicate accounts. Now, I'm not raising this point to say that Stephen's observations aren't valid though. Just that a "soft fail" should mean that you are given the option of aborting completely or continuing with the partial operation, rather the system forcing you only one way when this sort of error is encountered.

I was just thinking that for now, all emails sort of pass through a system check. If A) an email is in the system, great... just follow that registration protocol. If B) the email is not in the system, no problem, just sent out as a regular email and follow that registration protocol. If following path B the email bounces or doesn't exist, then just send the typical server mail delivery message to the user who sent out the invitations.

Once the invitation is submitted, I do see a green confirmation box that does a quick count to show how many emails the system just sent out (not withstanding success or failure of delivery) – just to give the user system feedback.

If you want to get a little bit more fancy w/rt to failure notices, you could send a follow up confirmation email to the site's contacts with a list of all failed emails.

But I don't know if I'd handle all that management in the UI as you guys have been describing – maybe it's just me.

WARNING: We cannot go forward with this until there are clearer requirements about how the users should be listed (by username, lastname, id order, ?) and looked up (by email, username, etc., ?) and even displayed (displayname only?, gmail style?, ?)

The Sakai 2.* "Site Info" workflow distinguishes between people who you expect to already be known to Sakai (in which case you can use ID, EID, or email address) and people who aren't already known to Sakai and who will need to obtain guest accounts. These different inputs lead to different notification messages and different immediate results.

Your picture only shows one input box, and, given the ambiguity, I chose to implement the "already known" case since that's the one I'm most familiar with. Instead, it sounds like you want the following:

1. Only accept email addresses as inputs.
2. If the email address is known to the system, use the "known user" workflow (in which the existing user is immediately added to the site and is optionally notified by email).
3. If the email address is not known to the system, use the "invited guest" workflow (in which a new user account is created with an EID, login name, and email address equal to the email address and with the default role "guest", and is notified by email, assuming the address is correct and with no real error handling).

Just a reminder (since I'm implementing that piece now) that we still have an open design issue to say just how the email notification to new members should be configured: who is it from, what's the subject line, is a link to the site included.... Also, the description is ambiguous about whether a notification should only be sent if an "Optional Message" was specified, or whether a standard notification message will always be sent no matter what. In SAK-14932 Stephen suggests that we build on Sakai's current "email template service."

I was going to ask if there is already an email template that Sakai uses for this. If not, I can design one, so please let me know.

Just off the cuff, given the open issue w/rt to site contact(s) or owner(s), which btw I still don't have an answer for, I would say for now the sender email should be a do_not_reply@sakai.com type email address.

The title should say something like "<name of user who sent out invitation> has invited you to join <name of site>".

The body should have a standardized message with a link to the site's gateway page where the user can either login (if he or she is registered) or register (if he or she is not registered). But again, doesn't Sakai have a method for this already? We can just default to that for now.

Regarding the custom message, it would append to the default template message and perhaps appear as:

The current Sakai email templates are somewhat sparse, and not good in that they lead to unnecessary support queries and/or hinder users in various ways (from years of production experience).

As a result, we some time ago changed our template for this to the version below which is considerably better. Many of these details are institution-specific, such as password reset processes and helpdesk information, hence the requirement to allow these templates to be customized outside the java code (which is why we wrote the email template service now in 2-6-x).

Note that there are potential variations to the form of the template depending on whether the user has been added or just invited to join (if such functionality will exist). Another unresolved issue is what happens when someone adds a user with an invalid email address (syntactically valid but undeliverable for some reason) - a guest account is created with an unusable email address and the site owner is unaware of it. These are lifecycle issues about the creation of guest accounts.

The templates also need to support per-user l10n (i.e. be sent in the target user's language).

Subject: $productionSiteName Site Notification: $siteName

Body:

Dear $userName,

You have been added to the following $localSakaiName site:
$siteName
by $currentUserName ($currentUserEmail).

To go to this site, login to $localSakaiName at $localSakaiUrl with your username ($userEid) and password.

You can then access the site by clicking on the site name, which appears as a tab in a row across the top part of the page, or by clicking on "My Active Sites" on the top right.