The web-based MCommunity Directory provides users with a public directory of people currently affiliated with the university, regardless of their original data source. It provides members of the U-M community with a web-based tool for updating and viewing their own directory information—both their own entry and their group ownership and membership. At a minimum, it will provide the same basic functionality currently available in the U-M Online Directory (UMOD).
It will include public information, such as each person's name, uniqname, and current university affiliations. Individuals will be able to select additional information to publish, and they will be able to select whether to make it available to authenticated or unauthenticated users.
See General Visibility of Person Attributes in the Governance Board Recommendations document for details about what will be publicly viewable.
The directory will also provide the capability to view, create, and manage directory groups.
The web-based MCommunity Directory is open in a limited capacity to the general web user population. Any web user will be able to look up a person with an MCommunity entry and get minimum record information. (See General Visibility of Person Attributes in the Governance Board Recommendations document.) General users will also be able to look up groups.
Additional information and functionality will be available to the members of MCommunity, that is, people who have an MCommunity entry and who can authenticate to the directory. This includes the following populations:
U-M faculty on all three campuses (Ann Arbor, Dearborn, and Flint)
U-M students who are Active in Program, including matriculated students on all three campuses
U-M current regular staff on all three campuses
U-M current retirees on all three campuses
U-M living alumni
U-M sponsored individuals, including U-M Online subscribers, temporary staff, and others
Also, directory administrators will need an administrative view of the directory for their work. Others, such as the Accounts Office and 4-HELP, may also need such a view. (We currently provide two administrative levels of access to UMOD. See Online Directory Access Policies and Agreement (R1452).)
Unauthenticated users will be able to do the following:
Search for, find, and view the entry of any person who has an entry in MCommunity and see the information that is considered public, as well as information the entry owner has chosen to make public. For each person entry type, this is the minimum public information:
Faculty and Staff Entries. Name, Uniqname, Also Known As, Title, Affiliation, E-Mail Address, Business Phone, and Business Address. A new display attribute showing campus is also public. For Retirees, Business Phone and Address are removed; right now, all retirees show up as affiliated with the Ann Arbor campus.
Students with FERPA flag set. Uniqname, e-mail address (in the form uniqname@umich.edu).
Students without FERPA flag set. Name, Uniqname, Also Known As, Title, Affiliation, E-Mail Address.
Alumni. Name, Uniqname (if they have one), Affiliation, E-Mail Address (if they have one).
Sponsored Individuals with Strong Identities. Name, Uniqname, Also Known As, Title, Affiliation, E-Mail Address, Business Phone (if they have one), and Business Address (if they have one).
Sponsored Individuals with Weak Identities. Name, Uniqname, Affiliation, E-Mail Address.
In UMOD, public information includes Do Not Spam List setting, Created By, Created, Modified By, and Modified.
In addition to the minimum public information, users may choose to publish the following in their entries: Description, Notice, additional business contact information, Home Phone, Home Address, additional personal contact information, On Vacation, Vacation Message, See Also, Proxy (displays if a proxy is set), and Favorite Beverage.
Search for, find, and view group entries in MCommunity.
Make use of "fuzzy searching" capabilities to help them find entries. Fuzzy searching offers people suggestions when they make typos. It provides alternative results for names that are similar to the search criteria provided, such as those that sound the same or those that are commonly misspelled a certain way. The search might, for example, ask the user, "Did you mean 'jones'?" if the user typed 'jons.' Current UMOD search returns exact matches only, and people find the fuzzy search results provided by Google and others to be much more helpful.
Use simple or advanced search options. (Advanced search will let people search by attribute, such as last name or address.)
Authenticated users will be able to see additional information that users have chosen to publish to the community. In addition, they will be able to do the following:
View all the information in their own entry whether it is public or not and select what they want to be publicly viewable.
Make changes to user-provided information in their own entry, such as their favorite beverage. They cannot make changes to information provided by an authoritative institutional source, such as M-Pathways. To change this information, they must change it at the institutional source. For example, people can use Wolverine Access to make changes to data stored in M-Pathways. The interface will make it clear where information must be updated. At a minimum, MCommunity will provide users with the same options as UMOD for modifying their own entries, with some exceptions. See The U-M Online Directory Via the Web: Finding and Changing Your Personal Entry (S4276) for details about UMOD options. See Differences Between UMOD and MCommunity below for more about the exceptions.
Join groups and remove themselves from groups where that option is available.
Create groups.
Edit groups that they own. At a minimum, users will have the same functionality for group management that they now have in UMOD. See Managing Groups that You Own in the U-M Online Directory (S4277).
Authenticated users with elevated access will be able to make certain changes to other people's entries as required by their job responsibilities. For example, the directory administrators can disable groups.
The following uses of the web interface to the directory will be considered inappropriate and will be prevented if possible and discouraged otherwise:
Data scraping. Data scraping, also called screen scraping, is a technique in which a computer program extracts data from the display output of another program.
Saving bad data. All data in MCommunity must either be provided by the owner of an entry or by an authoritative source. The user will not be permitted to change data from an authoritative source via the directory; the user must change it at the authoritative source.
Disclosure of private personal information. The directory will not make public any information that has been designated as private.
No more privacy flag. People will no longer be able to make their entire entry private.
No more turning off batch updates. People will no longer be able to prevent updates from authoritative data sources.
New defaults regarding what is and is not public. In UMOD, everything is published unless you ask for privacy. (UMOD privacy info.)
Faculty and staff will no longer be able to change/hide their titles. Their official U-M job title will be displayed. They will not be able to hide their official U-M job title. If they wish to provide an alternate title, they can do so by using the Notice or Description field.
Faculty and staff will no longer be able to hide their work address and phone number. They can, however, request that a general departmental phone number and address be used. They can also request that this information be hidden in special cases, such as those involving stalking.
Data on all living alumni will be included. In UMOD, people who have entries as students get the affiliation of alumni added when they leave the university, but other alumni are not included. This will mean lots of alumni entries that don't have uniqnames.
Flint and Dearborn students will be added. This will give them some new options. For example, they will be able to use mail forwarding. If they enter a mail forwarding address, they will then be able to use the Do Not Spam List and the vacation message.
Sponsored people will be added. The Sponsor System will create entries in the directory for sponsored individuals. This includes those with temporary unqnames.
Some UMOD entries won't be included in MCommunity. Every person entry in MCommunity must come from an authoritative data source (that is, M-Pathways, MCommunity Sponsor System, Dearborn Banner, Flint Banner, or the Data Alumni Constituent (DAC) database). This ensures that only current members of the U-M community have entries. There are a number of people in UMOD who no longer have an affiliation with the University listed in their entry. These include former staff and others whose entries were never deleted, as well as affiliates who were sponsored through a mechanism other than the Sponsor System. People without a listed affiliation will not be included in MCommunity.
There will be a new kind of group—role-based. These will be called roles rather than groups, though they will include group functionality. Their members will be members of a role rather than members of a group.
Some groups are used for access, such as access to a wiki, but this is currently not indicated in UMOD; that is, they look like any other group. It would be helpful to know from a group's entry if it is used for access, for e-mail, or for both.
MCommunity expands groups within groups (nested groups). We'll need to incorporate this into the user interface. We can show and hide the expanded groups.
Collisions between group names and uniqnames. People are able to create group names using LDAP commands and Also Known As group names using UMOD that are eight characters or fewer. If a uniqname is created that is the same as the group name or Also Known As name, mail is delivered to the uniqname. We intend to set things up in MCommunity so that group names and Also Known As group names must be at least nine characters to avoid such collisions.
People want to be able to remove themselves from groups. The policy has been to not allow this because of official groups such as those for all staff in a particular department. The goal is that this group function will eventually be handled by departmental roles. Then regular groups could be set to allow people to resign. One possibility as we move forward is to have new groups be resignable, but not joinable, by default.
The web-based MCommunity Directory immediately depends on:
Data in the MCommunity Directory from authoritative sources.
Data input from programmatic interfaces and individual users.
Having documented business rules about who should be able to view and modify information in individual and group entries under what circumstances.
Software that processes the business rules about who can view and/or modify which part of person data using the web interface.
Software that processes business rules about who can view and/or modify which part of group data in the Web Directory.
Users will need web browser software to access the web-based MCommunity Directory. We will not test for compatibility with unsupported browsers. We will not detect or block unsupported browsers. We will support the two most recent versions of Internet Explorer, Firefox, and Safari.
Ultimately, the MCommunity Directory depends on all of the downstream subsystems and MCommunity modules that are responsible for getting data into MCommunity, as well as the U-M systems that provide data.
Data feeds/drivers that connect to authoritative data sources: MPathways, Dearborn Data Warehouse (and, later, the Dearborn Banner System), Flint (Data Warehouse, and, later Flint Banner System), Donor Alumni Constituent (DAC) Data Warehouse, and the MCommunity Sponsor System. (Note: The Medical Center Information Technology (MCIT) programmatic feed goes to the Sponsor System via Web Services.)
OTID generation and handling in support of uniqname self-registration processing. OTIDs are the one-time identifiers people receive when they are eligible to have a uniqname. They enter the OTID, in combination with other information, via a web site where they create their own uniqname.
MCommunity Registry.
IDM processing (applying precedence rules, FERPA guidelines, privacy specifications and other policy decisions).
Native uniqname generation process. (Native uniqname refers to uniqname generation done by MCommunity rather than by legacy uniqname systems.)
LDAP tree read/write interfaces.
Institutional Roles processing
Departmental Roles processing.
Access Control Lists.
M-Pathways HEPROD.
Dearborn Banner System and Data Warehouse.
Flint Banner System and Data Warehouse
DAC (Donor Alumni Constituent—the authoritative source of alumni data) and DAC Data Warehouse
MCIT batch uniqname processing. (Interaction with MCommunity will be via Web Services to the Sponsor System)
ITCS authentication systems
Kerberos authentication
Cosign (single-sign-on for the web)
DNS services
During a transition period, the MCommunity Web-Based Directory will depend on some ITCS legacy systems until those legacy systems are retired.
The web-based directory depends on the ID Vault, which depends on legacy uniqname.
Legacy eligibility processing. This is the legacy eligibility database and associated processing that is currently used to determine who is eligible to create their own uniqname using uniqname self-registration.
We still need to determine how much of a dependency there is on UMOD. During a transition period, both UMOD and the MCommunity Web-Based Directory will be available to campus. We need to figure out whether and how to handle data synchronization for user-supplied data. We may need to make changes to the UMOD interface to let people know if updates they make there will not be passed on to MCommunity. We still have some things to figure out here.
These general requirements focus on meeting the needs of MCommunity Web-Based Directory users, unit IT staff, unit administrative staff, and central/MCommunity system administration and support.
Provide a transition period during which both UMOD and the MCommunity Directory are both available. This will lead to some data synchronization issues that remain to be resolved. Whatever is decided, communication and documentation will be crucial to be sure that people are not surprised by differences between the two directories, particular concerning information that they do or do not want to be publicly available.
Follow the rules and policies regarding data views as set forth by the MCommunity Governance Board. See General Visibility of Person Attributes in the Governance Board Recommendations document.
Follow institutional policy on the minimum data to be published for all faculty, staff, students, alumni and other affiliates, conforming to all applicable state and federal laws, and University internal guidelines (FERPA, FOIA, SPG, etc.)
We need rules for determining when person entries are removed from the public directory. For example, what happens when a student leaves the university or graduates? How does the entry transition from student to alumni? Do students who don't graduate just drop out? What happens when employees quit? When they transition from employee to retiree or emeritus faculty?
Include U-M branding with the technologies that theSponsor System (Java, Tomcat, Spring infrastructure, and XSLT for presentation layer) is using.
Implement controls to keep people from screen scraping as much as possible.
Follow usability standards for maximum amount of information displayed at a time so that users are not overwhelmed by too much information on any one page.
The web-based directory needs to work with the same supported browsers as the Sponsor System. That means the current and most recent versions of IE, Safari, and Firefox on Windows, Macintosh, and Unix. A December 2008 report of browsers used by current CTools users confirms that this covers the vast majority of U-M browser use.
Incorporate common technical standards, such as those for mobile devices.
The web-based directory is not intended to support applications that use screen data. Those applications should instead use the LDAP Tree. There may be some transition issues here, but they have not yet been identified.
Be ADA compliant: implement all Section 508 guidelines, all W3C Web Content Accessibility Guidelines (WCAG) 1.0 - Priority 1, most WCAG 1.0 Priority 2 guidelines, and many Priority 3 guidelines. Implement the proposed WCAG version 2.0 guidelines in place of 1.0 unless the specific guideline would cause significantly more work or the guideline is likely to change.
These people will have entries in the MCommunity Directory: current faculty, staff, and students; retirees, living alumni, and sponsored individuals.
These people, who currently do have entries in UMOD, will not have entries in the MCommunity Directory: terminated staff, students who did not graduate (DAC only sends seniors and graduates in its data feed), people who were sponsored in the past by means other than the Sponsor System (because they won't appear in any of the data feeds), former U-M Online subscribers and others who still have a UMOD entry but have lost their U-M affiliation.
A search of the directory searches entries from all three campus and includes all directory entries. The first release will not allow advanced searching by campus.
A basic search will search a set of indexed attributes, including names, phone numbers, and group names. The new directory will search at least the same fields that the current UMOD search does.
Some simple fuzzy field searches will be available, but not necessarily "sounds like" fuzzy searches.
Searches do not search any free-text fields. For example, Description and Notice are not included in searches. This is because such searches would require indexing those fields, and that is prohibitively expensive. A tagging system would be more efficient, and we will consider that as an enhancement for a later release.
An additional search option will be that people can search by first name in the new directory. This option is not available in UMOD.
Display the search operators used to construct the advanced search in the basic search box after submitting the advanced form. This will show the user exactly what they searched and give knowledgeable users a fast way to adjust their search (like this).
We need to provide, at a minimum, the same functionality for people entries as in UMOD, with some changes as set forth by the MCommunity Governance Board.
UMOD: Finding and Displaying Your Entry
MCommunity: Users will need a simple way to find and display their own entry.
UMOD: Changing Your Entry. Users can make text changes to these things: title, e-mail forwarding address, description, notice, business phone, fax number, pager number, cell phone number, business address (2), home phone, home address (2), more info (URL and label) (2), vacation message, see also (list uniqnames), proxy, and favorite beverage. They can also set these flags: private, use Do Not Spam List, on vacation, and prevent batch updates from changing my settings. Note that e-mail forwarding address can also be updated by using the mail forwarding address tool.
MCommunity: Users will need to be able to edit their own entry, but they will have fewer options for making changes. They will no longer be able to make changes via the directory to information that comes from an authoritative source. Instead, they will be directed to the source to update that information. Also, they will no longer be able to set the private and prevent batch updates from changing my settings flags. Because users can no longer edit their titles, MCommunity will provide a place where they can enter an alternative title (is that the description field?).
UMOD: Hiding Information in the Directory (Privacy)
MCommunity: The option to make an entire entry private will not exist in MCommunity.
UMOD: Disabling the Automatic Updating of Your Entry
MCommunity: This option will not be offerd in MCommunity.
UMOD: Setting a Vacation Notice
MCommunity: This functionality will continue in MCommunity. It only works for people who have an e-mail forwarding address in their entry.
UMOD: Designating a Proxy to Modify Your Entry
MCommunity: This functionality will continue in MCommunity. If you designate a proxy, that person can change your entry, change groups that you own, and change your membership in joinable groups.
We need to provide, at a minimum, the same functionality for group entries as in UMOD.
UMOD: Creating a Group
MCommunity: This functionality will be included in MCommunity. Users will also need to be able to create role-based groups.
UMOD: Making Changes to a Group
MCommunity: This functionality will continue in MCommunity.
UMOD: Finding All the Groups You Own
MCommunity: This functinality will continue in MCommunity.
UMOD: Deleting Groups
MCommunity: This functionality will continue in MCommunity.
UMOD: Renewing Groups
MCommunity: This functionality will continue in MCommunity, as will all the functionality surrounding group disabling and expiry. Note that administrators, such as Dir Admin and the IT User Advocate, need the ability to disable groups via an administrative interface.
UMOD: UMOD and IFS work together to allow people to save groups in IFS.
MCommunity: This functionality will continue in MCommunity. For groups in UMOD, this is done by perl scripts that contact UMOD at ldap.itd.umich.edu. Some changes to the scripts will be required to work against MCommunity, but they are minor. We'll have to decide how to handle the transition period when both UMOD and MCommunity are available. That is, we'll need to decide whether to make this option available via both systems at the same time or just one.
Group owners will continue to have the option to make a group private. This causes the list of group members to be hidden from public view. Only the owner and members can see the list of members, and they must bind to do so. Making a group private has no effect on mail delivery to the group.
As in UMOD, individuals will not be able to hide their membership in groups.
Additional information about group functionality in UMOD is in these documents:
Managing Groups that You Own in the U-M Online Directory (S4277)
Forwarding or Redirecting Your E-Mail Using the U-M Online Directory Via the Web (S4279)
Managing Your Membership in U-M Online Directory Groups (S4345)
These documents provide information about the attributes in people and group directory entries:
The U-M Online Directory Via the Web: Finding and Changing Your Personal Entry (S4276)
Includes a list of the items included in UMOD person entries, as well as descriptions of each.
Appendix B: Parts of a Group Entry
From Managing Groups that You Own in the U-M Online Directory (S4277)
Lists the items included in UMOD group entries, as well as descriptions of each.
UMOD to MCommunity Table (download table as PDF file)
Lists the items in a UMOD person entry and says which will be in MCommunity, the source of each data item, and where it can be changed, download the UMOD to MCommunity Table.
Attribute ACLs Spreadsheets (in MCommunity IFS space Data Schema folder; look for authentication attributes documents)
ACLs are Access Control Lists. They control who has what sort of access to each attribute of an entry.
There has been some confusion about these three attributes because they seem, at first glance, similar. The title is the person's official U-M title provided by M-Pathways. For retirees, the title is "Retired." For students, the title is, "Student" plus whether the person is undergraduate or graduate plus the college. Not everyone has a title. Most sponsored people won't have titles, but sponsored temporary staff might. Affiliation is also provided by M-Pathways or by virtue of the data source (for example, the affiliation of alumni is assumed for entries with data coming from DAC. It is the unit with which the person is affiliated along with whether the person is "Faculty and Staff" or "Student." If a person does not have an affiliation (e.g., a retiree), no affiliation shows up in UMOD. Title and affiliation are public information. Roles have not yet been implemented, so we don't know what they will look like or what will be displayed.
Present options for publishing information in such a way that the implications of making that information public are clear.
Ensure that the distinction between individual and group entries is apparent.
Represent clearly each person's multiple affiliations and roles and provide the associated data.
Ensure intuitive mail sending from an individual's directory entry. That is, when you view someone's entry, you should be able to send mail to them.
The Home Contact tab on a person's entry is grayed out if that information is not available to the viewer (either because the entry owner has not chosen to publish it or because it is not in the system). It must be clear to the user that this is the case.
Help and context-specific Help should be provided where appropriate and needed. Wherever possible, the UI itself should make clear to users what their options are and what they are viewing.
It should be quickly obvious to users whether or not they are logged in—and what the differences are between those two views (authenticated vs. unauthenticated).
Privacy of personal information is very important. It needs to be clear to the owner of an entry what information about them is public and private and what they can choose to hide or publish—and how they do that.
During the time when both UMOD and the web-based MCommunity Directory are both available, it needs to be clear to users if changes made to one affect—or do not affect— the other. The amount of synchronization has not yet been determined. Whatever it turns out to be, we may need temporary UI features in both UMOD and the MCommunity Directory so that users know how to handle privacy of information across both directories.
Contact information must be easy to find. Ideally, the user should not have to scroll to see it.
The See Also attribute was confusing to those who participated in usability testing. The UI/Help will need to make clear the use of this attribute.
Having e-mail settings such as the Do Not Spam List flag and the vacation notification in the directory is confusing to some people. Others have gotten used to them being there and expect it. The UI/Help will need to make it clear that these settings only work if an e-mail forwarding address has been entered.
Provide a mechanism to allow individuals to publish (to authenticated and unauthenticated users) personal attributes that don't fall under the definition of the minimum required data. These attributes will be hidden by default unless the user chooses to publish them by entering information.
Provide a quick search and an easy-to-find advanced search.
Display easy-to-use search results, perhaps with the ability to expand data about a person/group in a list.
It needs to be clear to students how they set the FERPA flag and what it means to have it set or not. Information about FERPA is available on the Ann Arbor Registrar's Office website (http://www.umich.du/~regoff/ferpafaq.html).
It needs to be clear when contact information is official and when it is not. For example, fax, pager, and cell numbers have traditionally been provided by the user in UMOD. MAIS is beginning to provide this information in some cases for employees. It needs to be clear in the MCommunity Directory when these are official U-M business numbers and when they are not.
It needs to be clear to users what the Vacation Message, Notification, and Description fields are and what they are used for. (In UMOD, we do this by providing Help buttons next to each field name on the Modify page.)
The Search box needs to be very easy to find.
Information that users have chosen not to publish should not be searched.
Users cannot modify the Also Known As field in their own entry. In UMOD, when users modify thier own entry, they see text telling them to send e-mail to nicknames@umich.edu to add names to the Also Known As list. This should continue. Also, it would be good to add that people must contact the ITCS Accounts Office to have names removed from that field. (Or we might want to see about changing that so that the people at nicknames@umich.edu do both.)
Users with extenuating circumstances, such as a personal protection order, can request that information otherwise considered public not appear in the directory. The UI/Help needs to explain the procedure(s) for requesting this. (The procedure is likely different for students versus faculty and staff, and likely varies across the three campuses. We still need to find out the procedure.
Users need to be able to provide additional (that is, information other than the official information in M-Pathways) contact information, including addresses and phone numbers.
The UI must prevent users from entering Also Known As names for groups that are eight or fewer characters. Group Also Known As names must be 9-64 characters in length. They must be more than eight characters to prevent collisions with uniqnames. They cannot be more than 64 characters because of a Novell limit.
The same character restrictions for group names and group Also Known As names that apply in UMOD need to continue in the MCommunity Directory. It would be good for the UI to enforce those restrictions if at all possible.
When people have requested use of a preferred name, both their preferred name and their legal name appear in the Also Known As field of their UMOD entry. In the web-based MCommunity Directory, they need to be able to choose to hide their legal name in that field. (They cannot remove it.)
People need a way to remove previous preferred names if they've changed their mind. Preferred names are added to the Also Known As field by the M-Pathways feed, but are not removed.
Fax number is user-entered information. It does not appear in the official data feed, so it is not displayed as part of the minimum public data for any entry (unless a user has entered it).
Directory administrators and others with elevated access should be able to log in as themselves to get their elevated access. (In UMOD, they must bind using a special ID; we don't want to continue this.)
As additional things, such as departmental roles, are added to MCommunity, the elevated access view will need to accommodate them.
Uniqname and e-mail address must be displayed as two separate items, even though it is obvious that one is derived from the other. This is so that people can copy and paste uniqnames and e-mail addresses. (This is currently the way it is done in UMOD, so this is just continuing existing functionality.)
Provide the capability for a user to export a v-card for a person. This must be set up so that only a deliberate act by a user results in the export. That is, the directory must preven automated scripts from triggering such exports.
The directory must be displayable on mobile devices.
Be "widgetable," that is, the directory must be set up in such a way that devices can get information from it for use in mashups. While we do not intend to provide this usage right from the start, we need to have a design that allows for implementation in the future.
Ensure that the web UI is easy and flexible to maintain and modify (on our own) by ITCS MCommunity staff on the page level, application level, and site level. It must be flexible enough to allow for changes and additions over time.
The e-mail address displayed in person entries should always be in the form uniqname@umich.edu. Actual forwarding addresses should not be displayed publicly. Only the owner of entry (and administrators with elevated access) should see the actual forwarding address in his or her own entry.
Provide a place where users can list online contact information such as Chat IDs (AIM, AOL, Jabber, Yahoo, other), FaceBook, etc.
In UMOD, you can see people's group ownership and group membership. This same functionality should continue in the MCommunity Directory.
In some cases, people would be better served by using ITCS's Listserv Service than by creating a directory group. The IT User Advocate, which also runs the Listserv, would like the UI to direct people to this service when appropriate.
People have asked whether the directory will display the following information from M-Pathways: student status, level, academic plan, major, and registration status; fculty and staff appointment start and end dates, percent of appointment, and department; faculty assignments and areas of expertise; alumni year of last degree. This information will not be displayed. However, individuals may choose to enter and publish this information in the Notice and Description parts of their entries.
Students don't need a Business tab unless they are also employees.
How many additional addresses can people add? They can add as much information as will fit in the free-text field for preferred contact information. The size limit for this field has not yet been set. This field may be used for personal and/or business contact information.
POST vs. GET. Limiting the use of POST to forms that permanently change a data record. For example, a form that updates a user's contact information should use POST. A form that submits a search query should use GET. Using GET where possible limits the possibility of breaking the user's Back button (or showing re-post warnings). GET requests are also bookmark-able. For example, if a user performs a certain search frequently, they can simply bookmark the URL to the search (just like you are able to bookmark a Google search).
Redirect After POST. Silently redirect the user away from the location where a form POSTs. This will further reduce the possibility of breaking the back button. Many of our forms will submit using AJAX, so in many cases this isn't even an issue. (More Info.)
CSRF. CSRF protection should only be used on forms that can cause a permanent change to a user's data record. Limiting the use of CSRF to these forms will reduce the possibility of accidentally tripping the CSRF code.
Sessions. Use sessions as little as possible or else make them completely transparent to the user. Users of the current UMOD never get a warning that their session has expired (other than from Cosign, of course). It would be nice to maintain that experience. Session expiration warnings confuse users. If sessions are used, any session data, tokens, or CSRF tokens should be stored in cookies and not sent on the query string.
Traditional and Ajax Output. Many parts of the UI will support Ajax style interaction. Therefore, we need data sent to the browser in both traditional and alternate formats. We prefer JSON data as it's more compact and JavaScript understands it natively. XML can also work, however. Regardless, we need to be able to specify parts of a data record. For example, rather than getting data for a user's entire profile, we need to be able to request only the user's contact information.
Clean, RESTful URLs. Clean REST-style URLs would greatly improve the user experience over UMOD. This recommendation only affects the URLs that typical users will see, not the back end. For example, the current UMOD URL for Babs Jensen's entry looks like this:
http://directory.umich.edu/ldapweb-bin/url?ldap:///uid=bjensen,ou=People,dc=umich,dc=edu
A better URL for users would be:
http://directory.umich.edu/people/bjensen
When the web team asks a customer to join our production announcement UMOD group, we email them this URL:
https://directory.umich.edu/ldapweb-bin/modify?changetype=subscribe&dn=cn=umweb%20production%20announcements ,ou=User%20Groups,ou=Groups,dc=umich,dc=edu&act=join
A better URL for our users would be:
https://directory.umich.edu/groups/umweb.production.announcements/join
Provide Help links to explain common roles and assist with using roles for authorization purposes. (Departmental roles will not be be ready for incorporation until a later release.)
Provide a Spanish view of the directory in keeping with the U-M Portal en Espanol.
Provide a way to download SSL/PGP Certificates.
Provide public key/PGP Key/KX.509 download capability.
Implement a generalized, searchable tagging system for people and groups. Tags could include academic areas of interest.
Instead of just Favorite Beverage, allow a user to display one or more fun facts from a list of fun facts OR remove this feature entirely. Perhaps we could also make it more like other applications users are used to and have favorite movie, favorite book, favorite quote, etc.
Integrate the MCommunity Directory with CTools.
Enhance the vacation notice feature so that users can set a start and end date for the vacation notice.
Allow departments to extend the directory with local sources of information. For example, allow a department to add a path to the user's departmental home directory.
Implement a generalized, searchable tagging system for people and groups. Tags could help users discover people and groups with similar academic or personal interests.
When adding members to a group, provide options in addition to uniqname and e-mail address for adding a member, such as a search method for looking people up.
Communication regarding private entries. Users who have set their UMOD entries to be private will need to be informed that this option does not exist in MCommunity. They need to be informed what their privacy options are.
Communication regarding no more turning off batch updates. In UMOD, people can choose to change their entry and not have it updated by the authoritative data sources. This will no longer be an option in MCommunity.
Some people who have UMOD entries won't have MCommunity entries. People who have UMOD entries but no longer have a U-M affiliation will not have entries in MCommunity. Some of these people may be using e-mail forwarding or may be members or owners of groups. They are no longer entitled to these services, but we should be aware of this so that 4-HELP and the Accounts Office are prepared to answer questions from users. This is also an issue for groups, because some of these people are members of groups.
These still need to be created.
Creating a UMOD entry (for each population)
Creating an MCommunity entry (for each population)
