E-mail1. 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 (45)
Aug 05, 2008
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, 2008
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, 2008
Ray Davis says:
A couple of comments on "Site Settings - General"... 1. "Site ID" - These scree...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, 2008
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, 2008
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, 2008
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, 2008
Ray Davis says:
One last (I think!) clarification on the "Site Settings - General" screen. The ...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, 2008
Nathan Pearson says:
I'm not sure what you mean. In my mock-ups... Current Status: Active / Inactiv...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, 2008
Ray Davis says:
I see – glad I asked! I was mistaking "Current Status: Active / Inactive" ...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, 2008
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, 2008
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, 2008
Nathan Pearson says:
I think we have already accounted for this in 7.4.3 http://confluence.sakaiproj...I think we have already accounted for this in 7.4.3
http://confluence.sakaiproject.org/confluence/x/DAA4Ag
Oct 09, 2008
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, 2008
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, 2008
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, 2008
Nathan Pearson says:
Sounds fine to me, but I suggest we consider this a future enhancement. It's a ...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, 2008
Clay Fenlason says:
Decidedly non-trivial, yes, and it's probably worth pointing out that it's deepe...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, 2008
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, 2008
Clay Fenlason says:
I fear you hear me saying things I don't intend. I mean only to encourage that ...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, 2008
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, 2008
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, 2008
Ray Davis says:
Before moving on to the "Site Settings - Members" screen, I'd better jot a coupl...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, 2008
Ray Davis says:
The "Site Settings - Members" graphic shows an "Invited" status in the same colu...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, 2008
Nicolaas Matthijs says:
That's fine RayThat's fine Ray
Nov 03, 2008
Ray Davis says:
Nathan/Nico, in "Site Settings - Members", should the software attempt to rememb...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, 2008
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)
Dec 08, 2008
Nathan Pearson says:
Actually, I think we'll find it less troublesome if we choose the latter option....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.
Dec 09, 2008
Ray Davis says:
Cool, I'm fine with not remembering previously selected items after an update &#...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.
Dec 09, 2008
Nathan Pearson says:
I see. Sounds like a bug – unless someone thought that's a desirable beha...I see. Sounds like a bug – unless someone thought that's a desirable behavior. But anyway, you're spot on. Let's try to preserve the sort order.
Dec 10, 2008
Ray Davis says:
It does it that way now because my default way to keep development going when an...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.
Nov 19, 2008
Ray Davis says:
"Site Settings - Members - Add Members" : Shouldn't the "Default Role for These ..."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?
Dec 08, 2008
Nathan Pearson says:
Sorry, I'm a little confused. Can you explain how and who the difference in tit...Sorry, I'm a little confused. Can you explain how and who the difference in titling would help?
Dec 09, 2008
Ray Davis says:
To me, at any rate, calling something a "Default" implies I'll have a chance to ...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.
Dec 09, 2008
Judy Stern says:
I'll voice my opinion (but Nathan should give the final word): It's better to le...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.
Dec 09, 2008
Nathan Pearson says:
Can't argue with that (not that I planned to). I was just curious where you guy...Can't argue with that (not that I planned to). I was just curious where you guys were coming from. Let's drop the word Default.
Nov 19, 2008
Ray Davis says:
"Site Settings - Members - Add Members" : When the user makes a typo (or some ot..."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, 2008
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, 2008
Stephen Marquard says:
One use case here is that someone will cut & paste a long list of usernames ...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, 2008
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.
Nov 28, 2008
Peter A. Knoop says:
Squeak I'll throw in the observation that sometimes you don't want partial suc...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.
-peter
Dec 08, 2008
Nathan Pearson says:
I was just thinking that for now, all emails sort of pass through a system check...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.
Dec 09, 2008
Ray Davis says:
Immediate user feedback is pretty useful when it's possible. There's some server...Immediate user feedback is pretty useful when it's possible. There's some server-side ambiguity confusing the discussion, though, as noted above:
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).
Dec 04, 2008
Ray Davis says:
Just a reminder (since I'm implementing that piece now) that we still have an op...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."
Dec 08, 2008
Nathan Pearson says:
I was going to ask if there is already an email template that Sakai uses for thi...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:
<name of user who sent out invitation> would also like you to know:
<custom message>
Dec 09, 2008
Stephen Marquard says:
The current Sakai email templates are somewhat sparse, and not good in that they...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.
If you cannot login to $localSakaiName, please see http://vula.uct.ac.za/password/ for details on how to reset your password.
If you have any further questions about $localSakaiName or how to access this site, please feel free to contact the $localSakaiName helpdesk by replying to this email or emailing help@vula.uct.ac.za.
Online help is also available by clicking on the Help link in any page.
Regards
The Vula Team, University of Cape Town