Tag Archives: directory

Class Photo Rosters now in the Course Hub

For more than a decade the Web Applications group and its predecessors have provided a popular “class photo roster” through the online directory to help instructors match names to faces. We are pleased to announce that as of today, the class photo roster is now a feature of the Course Hub.

As with the old version, the photo roster is only accessible to the instructor[s] of a course. We hope that by moving the photo roster into the Course Hub it will be easier to use and more readily accessible. While we don’t have a shutdown date yet, the old version of the photo roster will likely disappear when the online directory is next rebuilt (not until sometime after the current semester).

Faculty, please give this new feature a try (look for the Roster links in the Course Hub) and give us any feedback you may have.

Weekly Web Development Round-up April 18-22, 2011

To give our colleagues a better idea of what’s changed in our web applications each week, we’ll be preparing this quick list for publication each Friday. Not all of the details of each change are included below, but we’ll be happy to answer any questions you might have in the comments. Continue reading

“Display Name” Updating Automatically

The “display name” (or alpha name) shown in the web directory, Outlook address book, etc. had in the past been set so that it could only be corrected or changed manually. This process has now been modified so name changes entered into the Banner database are flowing through the Active Directory table and are subsequently updating the web directory, Outlook, Segue, etc. in the format Last, First Middle.

One enhancement which should help people out as a result of this change involves the “Preferred First Name” field in the Banner database. For records that have had this data entered into Banner, the “Preferred First Name” is now appended to the “display name” and enclosed in parentheses in the format Last, First Middle (Preferred First).

Requests for “display name” changes should now be sent to the following:

  • Middlebury college staff or academic year faculty:  hr@middlebury.edu
  • Middlebury college undergrad students:  Commons coordinators
  • MIIS staff or faculty: hrmiis@middlebury.edu
  • MIIS students:  Seamus Dorrian
  • BLSE students or faculty:  Elaine Lathrop
  • Language School summer staff or faculty:  Sandy Bonomo
  • Language School students: Kara Genarelli

It would be helpful to include the words “change display name” in the subject line of the e-mail message.

Photo Op!

Dear LIS staff,
Is your contact information up to date in the College Directory? Need to add a new picture – or update the one you have? If so, stop by Circ – I’d be happy to take your picture and show you how you can upload it to the College Directory. It’s easy and quick! Privacy settings can be adjusted to allow your picture to display to the world or only to the campus. Our new web pages go live at the end of this week – is your personal contact information ready?

Directory Updates for September

The first meeting to review the feedback posted to the Web Makeover Blog for the online Directory occurred this afternoon. We agreed to a set of updates that will be made to the Directory prior to the start of the academic year in anticipation of the retirement of the print version of the Directory. These changes will focus on ensuring that the information included in the print Directory is accessible in the online version and small improvements in the online interface. We won’t be completely revising how the Directory work at this time, as we expect further changes to occur as a result of the Web Redo Project’s revisions to our overall Search strategy.

Here is what I’ll be working on changing:

  • Add the Department contact information to the Directory as a downloadable PDF. This is already done! We heard loud and clear that the information in the front of the Directory needed to be accessible online, and we’ve added a link to a PDF containing this information. The added advantage of this being in PDF form, for now, is that we recognize that this is the type of contact information people might need when they are not able to access a computer, either because the power’s out, or they’re working in a location without access to a machine, or traveling. You can print out this information at your leisure as a quick contact list for these situations.
  • Add A-Z links at the top of the Directory interface. Clicking on a letter will show a list of people whose last name begins with that letter and you can click on their name to see their record. This will give you a quick way to glance through the Directory.
  • We will add a field to the search form that lets you specify whether you want to search for only Faculty, Staff, Students, Language School personnel, MMLA, etc.
  • We will add a field to let you search by just first name, or just last name.
  • Approval of new photos will transfer to HR, and possibly other departments as makes sense.
  • In coordination with HR, we’ll review the current display settings for each field. There may be changes to how display settings permissions are handled in the Directory.
  • We’ll investigate a way to provide access to an online form year round that lets people update their Directory information.

This may not appear particularly ambitious, but we wanted to focus on what could be completed by the start of the academic year and not set ourselves up to be in a position where we’d have to redo this all depending on the work we’ll be doing for the rollout of the new website in January. I personally think this list helps address many of the concerns raised in the comments on the Web Redo Blog.

How the Online Directory Works

In light of the decision to discontinue the paper directory and make the necessary improvements to the online directory so that it can supplant the paper version, I thought it would be helpful to outline from front to back how the current online directory works. This will be followed, later, with my recommendations based on your feedback and the strategic recommendations for our new website on how we can improve the directory.

Banner

The majority of the data displayed in the online directory originates in the Banner records of the students, faculty, and staff. These records are updated by the functional areas of the college responsible for maintaining contact information on these personnel: Human Resources, the Dean of Faculty, the Registrar, and their counterparts in Monterey. All these records are then periodically compiled into a set of tables that lists the people associated with Middlebury, the Language Schools, Monterey, etc.

Active Directory

Microsoft Active Directory is an application that maintains a record of all people and machines that connect to our network. When you log onto your computer in the morning, you are connecting to the Active Directory server to verify both your ser credentials and that the machine is part of the network. Many of our web applications also se Active Directory (AD) to authenticate your username and password. The AD record for each person has fields for their contact information, as well as metadata about the email and the groups to which they belong, such as All Staff, students, etc.

The AD is based on the Lightweight Directory Access Protocol (LDAP), an open framework sed by several directory platforms. Because of its ubiquity, many programming languages and applications allow access to the AD through LDAP for the purpose of authentication and directory lookups. This is the chief reason to do lookups in the AD rather than getting the information directly from Banner: the information is in a consistent form and can be accessed by nearly any application we design or purchase.

In order to get the information from Banner to the AD, a script runs periodically that syncronizes the AD with those tables mentioned in the previous section. Not all records in Banner are brought into the AD: only those of active faculty, staff and students. Many of our systems rely on this assumption for user authentication. For example, if you have an account in the AD, you can se EZProxy to access our library resources like journal subscriptions. Our license for these resources may not extend to all people for whom we have records in Banner. We may broaden the scope of records that we copy from Banner into the AD (or a parallel directory service) at some point, but doing so will require evaluating the authentication systems for all our web applications, a significant undertaking.

Each record in the AD has common fields for contact information (e.g. “mail” for your email address, “sAMAccountName” for your username) but there are some fields that we ave extended AD to introduce and some that we use in unconventional ways.

  • company: Most people in the AD have their “company” listed as “Middlebury”, however this field may also include “MIIS”, “Middlebury STU”, “Middlebury LS” and some other values. It is possible for someone to have two values here. For instance, Sunder Ramaswamy’s record contains both Middlebury and MIIS, which allows him to appear in both directories.
  • extensionAttribute7: Some records are not shown on the directory, either by personal choice or as determined by HR. If this field contains any value, no information about the person will be shown.
  • extensionAttribute10: We currently allow all users to set the display permissions for their directory record through the Change Information Form. This attribute in the directory holds these settings as a comma separated string. For instance, my field might contain “mail=none”, which means that my email address is hidden from nobody. The logic for the values in this field dates back over a decade and isn’t entirely clear.
  • extensionAttribute9: Almost every person in the directory has a photo associated with them, though many don’t show it. This attribute sets whether and how the person’s directory photo is displayed.
  • extensionAttribute11: The same as extensionAttribute9, but specific to whether the person’s photo is displayed in the Faculty Class Roster, which allows faculty to see a list of students in their courses with a photo next to each name.
  • MiddleburyCollege-alt-*: For each attribute in the directory, there may be a corresponding “MiddleburyCollege-alt-” attribute. These contain alternate values associated with the person’s directory record to display for other companies they might be associated with. For instance, a student who attends both the undergradate college and the Language Schools will have two different campus housing locations. The “alt” attribute for their housing location would hold the value for their LS housing, which is then shown on the directory during the summer. A similar scheme is used for people with records that show for Middlebury and MIIS.
  • There are other, smaller, idiosyncracies with the AD. We store cell phone numbers in the “pager” field because the system didn’t always have a field for mobile devices. Because we maintain several addresses for people (work, home, student dorm, student mailbox), we had to extend the schema to hold the additional information.

Photos

As I said, almost everyone in the directory has a photo associated with their record, but many don’t realize this. Public Safety maintains a server that stores all of the ID card photos taken for the college. Every night, a script looks at the contents of this server and imports into a separate database any new photos. We also get a disc of professional photos taken at the new faculty orientation at Breadloaf each fall and add these manually.

Departments

A little over a year ago, the Banner team introduced data validation to the department field for employee records. This was a huge relief as it meant that we could now rely on the department field in the AD for each person, rather than a static list or groups. Relying on group membership to determine department has always been problematic because the group lists are managed by the department and will often not include, for instance, faculty on sabbatical who do not wish to receive department emails.

Once a day, a script runs through all of the records in the AD and compiles a list of the departments associated with each record. This list is then used to populate the “department” drop down field on the Middlebury and MIIS directories. This still doesn’t fully solve the problems associated with departments, since some faculty and staff need to appear in multiple department lists. Brad Nadeau, the Communications Director for Athletics, has his department listed as “Athletics/Communications”. We don’t want this department to appear in the list, so we maintain a separate manual table of dual departments. Any departments on this list are excluded from the drop down. We then maintain another list of these departments to use as a reference, so that when you search for the “Athletics” department your search will include “Athletics/Communications” as well.

Stepping through a Directory Search

Let’s say that I want to search for people named “Ian” in “Library & Information Services”. I would enter my name in the Name field and choose “Library & Information Services” from the Department drop down list. When I submit the form, the following query is built to run against the Active Directory:

(&(CN=*Ian*)(department=Library & Information Services)(company=*Middlebury*))

There are a few other fields included so that the search results don’t include computers or network routers, but they aren’t really important for this example. The *’s around my name indicate that we’re doing a wildcard search. This will return results for anyone with “Ian” anywhere in their name. In contrast, the department search will only return exact matches for Library & Information Services. Even though I didn’t include it in my search, the system tacked on the company information because I did this search in the Middlebury directory, so it assumed that I wanted to see Middlebury people, rather than MIIS personnel. The & at the beginning of the request means that all of the search criteria must be fulfilled by the records included in the response.

The Active Directory then returns a list of the records matching those criteria. The online directory then loads a list of the default display attributes for each class of records (we have different default display options for students and staff). Each record is then checked first to see if extensionAttribute7 is set (hide the record entirely) and then iterates through all the other attributes to determine what the default display setting is and to check to see if the person’s record overrides the default setting. These values are also checked against the current state of the person requesting the information, since we have different display settings for on-campus and off-campus use of the directory.

When an attribute beginning with “MiddleburyCollege-alt-” is encountered, the script checks to see what the default company of the record is, what company context the requestor is browsing in, and whether the “alt” attribute has any information to display. For instance, if I worked for Middlebury and MIIS, my company attribute might be listed as “Middlebury,MIIS”. If I maintained offices on both campuses, my extensionAttribute4 (Campus Location) attribute might be “Library 132” – my Middlebury location – and my MiddleburyCollege-alt-extensionAttribute4 attribute might be 432 Pierce St – my MIIS location. When requesting my record on the Middlebury directory, the context company is “Middlebury” so the “alt” attribute is ignored in favor of the default attribute. The reverse is true for requesting this record on the MIIS directory.

Once each attribute in each record has been check, the directory compiles a new results list containing only the information that is permissable to display on the web. This interface is exposed through a web service to allow applications other than the online directory to make use of the information, if needed. The compiled results are sent back to the directory form, which iterates through each record and prints the results.

One more request is made for each directory record. The photos for each person are stored in a database as binary data. Each time a record is printed to the screen, we make a request to this database to see if the photo can be displayed. This request takes into account the current state of the requestor (logged in, on campus, off campus) and determines if it should show the image. If the image cannot be displayed, the seal of the institution is shown in its place.

Questions?

I hope this gives you a general understanding of what goes on when you make a request to the directory and helps you understand how the results you see are compiled. My hope is that our ongoing work helps to streamline and simplify this process.

Can we get rid of the paper Directory?

Here’s an extract from an email I sent out recently in response to this question. Some of the suggestions here would also help us improve how we structure user permissions, return search results generally, and consolidate how we display information about people accross multiple institutions:There are both programmatic and culture issues with the current Directory. Here are the things I think we’d need to change to really be able to get rid of the print Directory. By the way, I think the suggestion to have a PDF (or plain HTML with no search) version of the Directory is a really good one. This would deal with the issue of printing costs and provide a usable alternative to the search interface.

1. Cultural: You can hide information from the Directory. My phone number isn’t listed because I don’t like receiving phone calls and the Directory, ever since its first online version, has allowed people to hide whatever information they like (including their whole record). If we eliminate the print Directory, we need to reach an understanding on campus that certain information will always be displayed (which fields are default will differ between faculty, staff, and students) and that people can’t choose to hide their records. It’d be great, too, if we could encourage people to have a visible Directory photo, but I won’t push my luck.

2. Programmatic: There are no numbers to call for departments. Robert Armstrong in Public Safety feels the pain here, since he’s the first result when you search for that department and gets all the call directly, instead of people calling a central line. Bob Clagett gets a lot of this too, since there’s no contact information for “Admissions”, people just assume that they should send emails right to him. This is a rather easy problem to fix: I just need to compile a list of department contact information and program the directory so that you see it as the first listing if you search for only a department.

3. Programmatic: The search algorithm kind of stinks. It is incorrect, by the way, that you can’t browse all the T’s. Enter T into the “Person’s Name” field and see for yourself (please don’t actually do this). Realistically, we should be using the GSA: providing it an RSS feed of Directory information to crawl and letting it handle Directory search results. I’m not sure how well the results would come out, but we could have this system operate side-by-side with the current search to provide more options.

4. Cultural/Programmatic: The org chart at Middlebury is a closely guarded secret, for reasons I’ve never fully understood. It would seem to make sense on the Directory that some level of organization is presented. For instance, I should be able to search the Directory for the Web Services (or whatever we’re calling ourselves) group and see Joe listed at the top as manager with Adam’s, mine, and Travis’s profiles listed below in alphabetical order. Ideally, the page would also have a link to the ETI listing, with Jeff at the top. This is a bit trickier to implement than the others because none of this information is tracked in the AD.

I’ve written four versions of the Directory application so far while working here and these same issues keep coming up. Another thing to note: the Directory is the only design template we received from Big Bad that was implemented in an application outside of the CMS (it was actually in the CMS for one of those four versions). I would expect WW to include some form of design for the Directory in their deliverables.

Note: since I wrote that email, I’ve found ways to improve how the Directory search works and implemented some of those ideas in the custom search interface referred to in my post yesterday. I no longer strictly believe that we should feed Directory search results through the GSA.

Update from Database Applications & Systems

Submitted by Chris Norris

Here are some of the projects and tasks that DAS staff members have been working on during the past month…

Mike Schuster
– Created a spec for Bookstore Upload / Course Listing Bookstore Links
– Researched problem Off Campus Study was having pushing Admissions applications
– Corrected problems with Bread Loaf, Language School, and Off Campus Study decisions processing reports, reports were broken due to System 9 upgrade
– Created SSB web package to allow residential systems coordinator to delete room draw preferences, reorder preferences, and activate/inactivate room draw applications
– Processed Fall 2008 course response form data
– Updated Feb’s MNET email addresses to “preferred”
– Fixed problem with LS & BLSE Financial Aid online web applications where bad data entry selection of dates in dropdown boxes would cause applications to get an Oracle error
– Modified custom p_assign_boxes database procedure to allow mail boxes to be assigned to students during winter term
– Worked with Liz Whitaker-Freitas and Marcy Smith to develop documents needed by Monterey staff when developing/requesting new reports

Liz Whitaker-Freitas
– Supporting Hyperion BI+ for functional & technical users
– Troubleshooting Admissions Decisions reports
– Coordinating roles to groups migration by Velaris

Ian McBride
– Added service to check GO addresses nightly
– Worked with Adam to develop web service for MiddTube
– Wrote WordPress plugin for MiddTube
– Developed Middlebury theme for WordPress
– Added a service to the Directory to automatically redirect to a user’s homepage
– Added a video icon to CMS home page news items with videos
– Developed home page for the New England Review site in WordPress
– Began investigation into Single Sign On applications
– Continued work with the Platform and Design/IA groups for the Web Makeover
– Finally launched News Portal at http://go.middlebury.edu/news!

Travis Stafford
– Created 7 new alumni event forms
– Tested WordPress CFORMS upgrade
– Upgraded all the WordPress blogs and cforms to the new version of CFORMS (13 blogs / +/- 50 forms)
– Completed porting over all the cat standard ecommunicate forms to CFORMS
– Minor changes the New England Review ecommerce form
– Troubleshot\Fixed issues with the CCAL Fundraising ecommerce form
– Added new functionality to the BLM application to show Counts by indicator flag for Banner-ListManager admins
– Added self service component to the BLM project for subscribing\unsubscribing to Newsletters and List Manager lists
– CFORMs support/training for various departments
– General support and HEAT tickets

Rob Pekor
– Rolled late graduates to Alumni
– Started developing and creating tables to hold Harris Online Directory data
– Started creating scripts to load initial data for Harris Online Directory
– Started very preliminary development of process to send updates to Harris
– Corrected problem with Phonathon SSB data selection page, page would error on multiple individual years selected, problem has been corrected and is now in production
– Created new function to retrieve a list of regions for a particular person
– Corrected problem in AIA relating to updating ask amounts, if an ask amount never existed before for a person, the SSB page would not update the value, problem has been corrected and is now in production
– Created list of people that currently have access to AIA
– Corrected issue with view for the Banner List Manager relating to the indicator for students

Chris Norris
Staffing
– Participated in telephone interview for open DBA position
Projects
– Reviewed Phoenix BIA reports and summary
– Worked on spec for remote DR web presence
– Participated in CA fundraising strategy meeting
– Refined Banner-ListManager project spec with DAS staff
– Completed work with CA and Communications on Organic Garden giving form
– Met with DOC and PS staff regarding new ER web presence
– Met with technical/functional staff regarding eCommerce options for “pay-for-print”
– Met with Communications staff to plan for upcoming Newsletter projects
– Met with Career Services staff to plan for upcoming Newsletter projects
– Participated in various Web Makeover team meetings
– Met with HR staff regarding Web Makeover requirements
– Met with PHC staff regarding Web Makeover requirements
– Met with PS staff regarding Web Makeover requirements
Systems Administration
– Ongoing monitoring and problem resolution of online services
– Resolved service outages for Banner and Hyperion
– Resolved server config issue for GoogleEarth version of campusmap
– Updated TouchNet server config to support additional web servers
– Upgraded SubmissionManager web application for BLWC
– Configured new GO rewrite rules
– Ongoing tuning of GSA to improve search results
– Renewals of College-owned domain names
– Met with SNS staff regarding HSF config options
Help & Support
– Provided support to CFA staff for artsmail Newsletter IA
– Provided support to HR staff for middleader Newsletter buttons
– Reviewed President’s Holiday Card for pre-sending issues for Communications
– Updated Middlebury’s United Way web presence (campaign stats)
– Updated AbroadView.org web presence (footer)
– Provided various support for CMS editing, HEAT tix, and ad-hoc help calls
Vendor Related Activities
– Participated in Sun-Guard/SCT Banner DBA weekly status calls
– Participated in Velaris Hyperion SysAdmin weekly status calls
– Continued contract re-negotiation with Hyperion SysAdmin vendor (Velaris)
– Worked with DavisProjectsforPeace.org external web vendor to grant direct database access
– eCommerce call with alumni online community vendor (Harris) to define IMA requirements
– Coordinated redirect request from MIIS staff with www.MIIS.edu web vendor (NeptuneWeb)