Information Technology

2007-04-06

Submitted by Paullette M. Leukhardt

Absent: Heather Mainville, Laurie Bouchard, Patricia Pelletier

Other Attendees: Katie Edwards, Lee Barstow, Ellie Ballard

1. CMS -

Information Technology – login – IT – about IT – Committees – CORE Team

Please review. At our next meeting we will adjust the information about this team per your recommendations.

Agenda and Minutes will be posted here. I will copy the minutes from Possibility starting January 2007 and put them on the web.

2. Admission needs a new music interest in the INTERESTS code file.

AXVO Adm Music Voice ALL

The music dept. requested that all voice (AXAL = alto, AXBA = bass, AXSO = soprano, AXTE = tenor, & AXVE = voice, unspecified) be one code. Because of historical data for the past 5 years, I think a new code needs to be set up. These other codes will no longer be used.

INTR - added AXVO code 2007-04-09

3. Admission - Who maintains what CORE shared data & who has update maintenance to name & address screens;

I would like this to be a topic discussed at the meeting. The attached is an example of another department maintaining an applicant. It happened during the time that letters were being printed & being proofed. I know that a lot of people have access to update information on NAE & ADR etc., but the rule is if you know that a change should be made because you have a written request you should only change data for a person who has your department source code. If it doesn't have your source code you need to send the information to the office who the data it is for. For example, when we do the move-to-student process for applicants who have deposited, we no longer update those applicant's data. We send the information for the update to the Registrar's Office. It's just like having access to venders or employees etc.. If the person has EMP or VEN or another office's source code, that office should be making the change. This change was made during a critical time when decision letters were being produced. This makes us very nervous! We don't know exactly what changes were made, why were they made, and where is the written information triggering this change (documentation backing up the change).

Advancement will continue to add the parents and relationships in Colleague for the accepted students (accepts who deposit, DPD or DWV) but not before the April 1 mailing date next year.

 

4. CMS – from prior meeting - Advancement concerns to finalize for all CMS people

a. Recommendation below will improve name search results by finding more people with matching last name and first name data.

New formatted name codes for preferred name data as fielded data, prefix, first, middle, last, and suffix is setup. Advancement will need to do data entry to use these data fields (2500 people with free form text preferred names).

New CMS resolved name data for fielded name data will use the above formatted preferred name data and the legal name data.

The resolved name data will appear in the public section and the legal name data will stay in the personal section.

In CMS the nickname will need to move to the public section. Agreed? OK

From the resolved fielded name data created a single resolved preferred text name field with prefix, first name, middle name, last name and suffix.

In CMS we will no longer show in the personal information section the free form database text field that contains the preferred name.

Resolved Name rather than Resolved CMS name or Resolved Preferred Name.

b. Searching for a first name will scan resolved first name, nickname and legal first name.

Searching for a last name will scan resolved last name and legal last name.

c. Name presentation recommendation for all users (faculty, staff, students, alumni, others, etc.) of CMS as follows:

Profile search results – resolved preferred text name with rollover or resolved last name, first name, middle initial (informal without prefix and suffix)

Attribution – resolved preferred text name and username in parens or resolved first, middle initial, last (informal without prefix and suffix)

User list – resolved last name, first name, middle initial

User search – resolved last name , first name, middle initial and username in parens

Classmates list – resolved last name, first name, middle initial with rollover

Homepage name - resolved last name, first name, middle initial

Webpage name – resolved last name, first name, middle initial

Rollover name will include the resolved prefix, first, middle, last, suffix, nickname in parens (if not the same as first name), and the class year (with parens and brackets as currently coded).

The position title data is not available to be used with attribution.

d. A new public text field will contain deceased, widow/er and text for trustees, if the person has the appropriate codes in the database.

e. Per Stacey -

In general, our policy (and therefore official college style in the college's print and electronic publications produced for the widest audiences) is:

-- to refer to students and alumni (and parents) w/class year attribution (so: Axel Schupf '57)

-- to include professors' actual titles, but not honorifics, and to also include class year if the faculty member is also an alum (so: Javier Corrales, associate professor of political science OR William H. Pritchard '53, Henry Clay Folger Professor of English)

-- to refer to staff by their titles, but not honorifics, and include alumni year if the staff member is also an alum (so: Betsy Cannon Smith '84, alumni secretary and executive director of alumni and parent programs)

Per David - the longer representation of an individual's title as displayed per the examples is almost certainly too long for the web and would look pretty busy in the attribution line for a user.


5. New CMS issues –

a. Advancement proposal is add to the search the ‘name while at amherst’ free form text data field for matching first or last names. Name while at Amherst contains the transcript name (degree name) starting with classes around 1977 and if none present then the maiden/birth name from benefactor.

b. alternate fielded data for cms in searching is Benefactor maiden/birth name data (last, first, middle).

We could add these fields to the personal section and use these first and last names when searching. Record the entire birth name or only last name for those alums who have changed their names after graduation or after leaving AC.

The three benefactor birth name fields will be added to the personal section without the ability to be updated. Advancement will attend to any database updates to support these data fields. The maiden/birth name first and last names will be included in the search for first and last names.

In CMS these will be referred to as the fielded name while at amherst data (first, middle, last). These will appear in the public section in order to be searchable.

c. simplify the city, state and country search to scan home address, alternate address and mailing address city, state and country fields. This will work for all cms people who have any address data in home (PER), alternate (ALT) or mailing (MAI).

 

6. New CMS people

The accepted applicants are being added to the CMS core data file very soon. The role is to be named ‘Accepted Applicants’. Once the matrics are moved to student status in Datatel, shortly thereafter the AC email addresses are setup as well. This all happens during early June. Admission verify admission email address during the matric and AC email address load.

Per the CORE Team

One opinion is not to put up all accept applicants (1165) but only the students who have indicated that they have accepted us (deposited DPD and DWV).

The Registrar is very concerned that we are very close to violating FERPA. He does not think that all accepted applicants should be a part of CMS.

Additionally, all accepted applicants will be able to see and review all alumni the same as currents students can do.

Another thought is to encourage those accepted by having them out in CMS to see our world, maybe??


7. HR review again, PID3 word substitution (From 08-04-2006 minutes)

ste = suite, ave = avenue, ter = terrace, cir = circle, apt=apartment, hwy=highway, etc.

word substitution applies to all fields and all locators (corp looks ok but person not ok)

person locator rule is to use 3 char last, comma, 3 char first

if you use any of the above PID3 3 char word substitutions

you do not get a locator screen returned as none are found

one work around = put an * before the first or last name, examples ser, *ter or *ste, pau

or search using 2 or 4 chars to get results for ste, ave, ter, etc. in either the first or last name

examples ser, te or ser, terr or stef, pau or st, pau

Core Team recommendation = use * or 2 or 4 chars for one of the six 3 char pid3 entries

From an email 08-11-2007

There are Datatel Colleague parameters that are defined by the Core Team which automatically provide the long spelling for certain abbreviations, for example, ste = suite, ter = terrace, cir = circle, ave = avenue, apt = apartment, hwy = highway, rm = room, rd = road, ct=court, pl = place, ln = lane. Primarily this word substitution supplies the full word rather than the abbreviation automatically in the address fields.

If you use any of these two or three characters combinations as the search criteria in the name lookup for either first or last name, then the word substitution is invoked behind the scenes and hence you do not get the person locator screen.

One of the Datatel recommendations is to put an asterisk before the partial name, for example, plo, *ste will find plotner, steffen on the database whereas plo, ste will not. The other recommendation is to use more or fewer characters than the defined abbreviations so that a match does not occur with the word substitution parameters.

The core team will review all PID3 word substitutions at a future meeting.

8. No meeting Friday, April 13th. We will meet Friday, April 27th.