1. Site Home Page
1. Site Settings
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 users
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?, ?)
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
ToDo :
| Domain | Description | Work Estimate |
|---|---|---|
| Design | Rename tab | 10 min |
| Total: 10 min |
Comments (32)
Aug 05
Nathan Pearson says:
Issue 3.3.3 I think if we head down this path, it might make sense do build out...Issue 3.3.3
I think if we head down this path, it might make sense do build out an ultra light version of the My Profile widget. What do you think?
Aug 05
Nathan Pearson says:
Issue 3.3.5 Personally, I think it should be the last time the user signed into...Issue 3.3.5
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.
Oct 06
Ray Davis says:
A couple of comments on "Site Settings General"... 1. "Site ID" These screens d...A couple of comments on "Site Settings - General"...
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?
2. "Current Status: Active / Inactive" - I'll assume this is the same functionality as Sakai 2.*'s "Publish" checkbox.
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.
Oct 06
Nathan Pearson says:
1. This is a static reference, not an editable form field. 2. Yep 3. Great point...1. This is a static reference, not an editable form field.
2. Yep
3. Great point! I'm actually thinking there might be a way of pulling these options into the Members screen.
Oct 07
Ray Davis says:
Nico's OSP / Content Authoring demo had the "Site Settings" link pop up a widget...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.
Oct 09
Nathan Pearson says:
Ray, the Site Settings lightbox that Nico added is a bit confusing because it's ...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.
Nathan
Oct 09
Ray Davis says:
One last (I think!) clarification on the "Site Settings General" screen. The Si...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.
Oct 09
Nathan Pearson says:
I'm not sure what you mean. In my mockups... Current Status: Active / Inactive ...I'm not sure what you mean. In my mock-ups...
Current Status: Active / Inactive = Display in public list
The Site Is: Public / Private = It can be joined / or not
Oct 09
Ray Davis says:
I see glad I asked! I was mistaking "Current Status: Active / Inactive" as equiv...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.
Oct 09
Nathan Pearson says:
This is good usability feedback. I think we should change the options to read: ...This is good usability feedback.
I think we should change the options to read:
Current Status: Opened (Available) / Closed (Hidden)
Can be joined by: Only people you invite / Anyone
Oct 09
Stephen Marquard says:
There are additional site access modes which aren't currently available in the U...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).
Oct 09
Nathan Pearson says:
I think we have already accounted for this in 7.4.3I think we have already accounted for this in 7.4.3
http://confluence.sakaiproject.org/confluence/x/DAA4Ag
Oct 09
Stephen Marquard says:
It's not what's described in 7.4.3. It's the ability to go directly to the site ...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.
Oct 09
Nathan Pearson says:
I see. Are you requesting for this functionality to be added to the UI?I see. Are you requesting for this functionality to be added to the UI?
Oct 10
Nicolaas Matthijs says:
I would say this is important enough to be added to the UI.I would say this is important enough to be added to the UI.
Oct 11
Nathan Pearson says:
Sounds fine to me, but I suggest we consider this a future enhancement. It's a b...Sounds fine to me, but I suggest we consider this a future enhancement. It's a bit less trivial than a UI bolt-on.
Oct 12
Clay Fenlason says:
Decidedly nontrivial, yes,...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.
Oct 12
Nathan Pearson says:
Your comments refer to an investment dilemma that I understand and sympathize wi...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.
Oct 13
Clay Fenlason says:
I fear you hear me saying things I don't intend. I mean only to encourage that 3...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.
Oct 11
Clay Fenlason says:
I would "third" that. Our preference locally has long been an Amazon model of p...I would "third" that.
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.
Oct 20
Judy Stern says:
I know we can worry about precise wording later, but with your new text I'm stil...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.)
Oct 17
Ray Davis says:
Before moving on to the "Site Settings Members" screen, I'd better jot a couple ...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.
Oct 24
Ray Davis says:
The "Site Settings Members" graphic shows an "Invited" status in the same column...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.
Nov 04
Nicolaas Matthijs says:
That's fine RayThat's fine Ray
Nov 03
Ray Davis says:
Nathan/Nico, in "Site Settings Members", should the software attempt to remember...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.)
Nov 04
Nicolaas Matthijs says:
Ray, I'm not quite sure. I would be inclined, looking at other applications thro...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".
Nathan, can you do this ASAP (given that Ray needs this)
Nov 19
Ray Davis says:
"Site Settings Members Add Members" : Shouldn't the "Default Role for These Memb..."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?
Nov 19
Ray Davis says:
"Site Settings Members Add Members" : When the user makes a typo (or some other ..."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.
Nov 24
Ray Davis says:
Another error case reported by Site Info: "The following participants are alread...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.
Nov 25
Stephen Marquard says:
One use case here is that someone will cut & paste a long list of usernames / em...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.
Nov 26
Ray Davis says:
Thanks, Stephen. As the saying goes, "the squeaky wheel designs the car," so I i...Thanks, Stephen. As the saying goes, "the squeaky wheel designs the car," so I implemented your suggestion.