Patron Records: We would like the ability to store one or more alternate name fields. This would make it easier to find records under former names or different configurations of the same name
This idea was ported over from the Google Moderator account, where MassLNC had previously been tracking some development ideas. Originally suggested by Elizabeth Thomsen.
The way names are currently stored this is not possible.
Either a secondary name storage would be needed (complicating search that has to look at two places) or all names would need to be moved to a new table. The latter is a significant schema change that may have very far reaching consequences and is not to be considered lightly.
Either way a method of editing multiple names would be needed as well.
I understand this could be complicated, but I still want to hear how important this idea is to people to see if we need to proactively advocate for a solution.
I do believe this is a big deal. Many patrons in the system use hyphenated last names inconsistently, have maiden and married names, have names with a hyphen or apostrophe in them, use their nickname or middle name sometimes instead of their first name. Many of these issues could be addressed by really scrupulous and highly standardized patron info entry across all CWMARS libraries... but that's not going to happen.
Multiple name fields would prevent a LOT of duplicate records being created. They were possible in Millennium, so we know it can be done.
It's a big deal here, too. Even with the most scrupulous data entry practices, it's hard to keep up with name changes. Patrons give their current version of their name, and may not think to tell you the former version that their card is under, especially if it's been a while and it's not a recent change. We also have problems with people who anglicize their name over time, and may have registered as one form of name and now use another. We've had alternate name fields in all our previous systems, and really miss it in Evergreen.
I wanted to revisit this topic and say that it remains a big deal, a daily problems that results in frequent confusion, difficulty in finding records, multiple records being created for the same patron,etc.
In general, I'm very happy with the changeover from Millennium to Evergreen, but this is a HUGE loss of functionality and a constant headache.
I wanted to revisit this topic and say that it remains a big deal, a daily problems that results in frequent confusion, difficulty in finding records, multiple records being created for the same patron,etc. In general, I'm very happy with the changeover from Millennium to Evergreen, but this is a HUGE loss of functionality and a constant headache.
See also the http://masslnc.org/node/3222 for a suggestion to provide a place for a Preferred Name.
Reading the use case from that idea raised some questions for me. Do we also want the ability to designate one of these alternate names to be the one that is used for holds slips, notices, etc.?
We do have a Holds Alias available in Evergreen that can be configured to be used on the holds slip, so there is already some logic to allow for the holds slip to use something other than the standard name.
I can think of a number of use cases where alternate names would be useful:
In all cases we would want the ability to "tag" a name with a status such as "prefered", "legal", "former", etc.
In reference to number 3 above, we have new code that will be available in 2.11, courtesy of Dan Pearl at C/W MARS, that will address the issue with names entered with or without spaces and with names that have diacritics. From what I understand, it doesn't address punctuation, but I prefer that punctuation be handled in a similar manner instead of using an alternate name field. Basically, it should be stored and searched without the punctuation, making it findable no matter how the user enters it.
Our C/W MARS patron registration policy includes instruction to avoid punctuation. For example O'Connell is entered OCONNELL (we enter all names in caps). This policy was created originally to be uniform with postal standards to ensure overdue notices would be delivered. The postal standard states punctuation may be omitted with the exception of the hyphen in the zipcode + 4 code. It is fair to say my postal standard book is from 1997.
The hyphenated names can be a problem however and some patrons object to removing the hypen so that is why we say avoid punctuation.
I absolutely support normalizing names for search and retrieval so that punctuation is not required but can still be kept for display purposes. That said, it won't help with all the use cases covered by 3 above. For example, we have some patrons with names which must be entered like "J. John Smith" but who go by "John Smith" and don't think to tell us about the initial when we ask their name.
We do have some patrons that object to removing apostrophes in their names in printed materials. I think it would be better to normalize only when needed, i.e. removing apostrophes and capitalizing when printing address labels, but retaining the original capitalization and and punctuation so that it can be rendered correctly in other cases.
I'm moving this idea to planned development as a result of the December 15, 2016 vote on the MassLNC Development Committee. MassLNC will begin writing up requirements for this project so that the project can be issued for quotes from potential developers. Moving this idea to the planned section does not mean we will definitely fund the project. The final decision will be based on the quotes we receive and the funds we have available for projects.
Posting preliminary requirments for this project at http://masslnc.org/node/3303. Mockups are still forthcoming, but the requirements should give folks and idea of what direction we're taking with this project. Feel free to let me know if you have any feedback.
I'm replying here since I can't reply on the requirements page.
I think we may regret 1. b. "If an Evergreen site has designated any of the above fields as required when entering the primary name, the field should also be required for each iteration of the alternate name." What would be the reason for implementing such a requirement?
I think we should require that the preffered flag be assigned to exactly one name. As written the requirements suggest that the preffered flag can be assigned to no more than one name.
Number 5 describes a mechanism in which the user can hover over an icon to see the full list of names. This is fine, but we should be sure to support input methods that don't allow hovering and to make sure folks can select and copy the text if they need to do so.
I think we also need to address how patron search results are displayed.
Will every name matching the search display separetly in the results (possibly listing the same patron multiple times)?
And if we choose to display each patron only once, which names do we display? The name that matches? The primary name? The prefered name? All three?
My vote is for listing each patron only once, which would mean we would probably want to display up to three names for when the prefered name, the primary name, and the matching name are different. Perhaps we could use the existing columns interface and add columns for primary name, prefered name, and matching name?
There are a lot of questions about how this should appear, how search results should be sorted by default, and so forth.
Some patrons will not have alternate names and these fields would not be necessary. I don't think the fields should be required but could that be configured by library?.
I like the idea of the column picker to display the columns of the users choice.
>>I think we may regret 1. b. "If an Evergreen site has designated any of the above fields as required when entering the primary name, the field should also be required for each iteration of the alternate name." What would be the reason for implementing such a requirement?<<
If I recall correctly, the discussion during the working group phone call centered around requirement 6 - if the preferred name is going to be printed on hold slips and other receipts, then the preferred name should be a complete name. For example, if John Smith's preferred name is just listed as Jack, then the hold slip would just print out "Jack" which would cause confusion.
>>Number 5 describes a mechanism in which the user can hover over an icon to see the full list of names. This is fine, but we should be sure to support input methods that don't allow hovering and to make sure folks can select and copy the text if they need to do so.<<
I wonder if clicking on the little button to show a small pop-up window would work better for both accessibility and copy/paste purposes?
We had talked about staff being able to enter as many alternate/former names as necessary in a way similar to how multiple former addresses are entered (just click a button to add another set of fields). If we are going that route, then I think it needs to be clarified in the requirements. (Likewise, if we are just going to have a limited set of alternate name possibilities, it should be clarified.)
If we are going to allow an unspecified number of alternate names, then using the column picker to display them all in separate columns in the search results would get unwieldy very quickly (and that screen is already cramped for space). What if all of the alternate names were grouped into a single column that could be turned on/off with the column picker? So 'John Joseph Adams' would display in the primary columns and then 'Jack Adams, JJ Adams' would display in the Alternate Name column?
Thanks everyone for the feedback! I'm going to address each of the points in this question.
Required fields: I just want to clarify one bit of information here. The fields are only required if you are entering an alternate name. As Terran mentioned, I envision the UI components can be similar to the additional addresses we have now where you will click to add an alternate name if one is needed. I was hoping to convey that idea in the mockups, but I'll make sure it is addressed in the requirements as well.
The circ working group did spend quite a bit of time discussing whether we should require these same fields or if it would be okay to just enter a first name or just a last name. Terran touched upon this, but it came down to the fact that these fields are not only used for searching, in which case only one field would be necessary, but, in the case of a preferred name, could also be used for display purposes as well. We want to make sure if the preferred name is used in a notice, holds slip or receipt, it contains a first and last name. In cases where there is only a first name, we could teach the system to be smart enough to add use the primary last name, but it seemed more straightforward for the end user if they clearly could see how the name will read on those notices.
Benjamin, why do you think the downsides of this requirement are?
Exactly one name: Yes, I can make that clear.
Icon: There was a lot of concern here about cluttering up the sidebar with too much information since users need the most important information to display without the need to scroll. We could follow up on Terran's idea to accommodate the need to copy. However, that won't help with the providing a way to access this information without using a mouse. Here's another thought. What if we have the icon with the hover behavior, but also include the alternate names in the sidebar, but at the bottom of the screen? It's a bit redundant, but the icon could provide a visual cue for people to scroll down if they want to view that information without using a mouse.
Patron search results: Yes, you're right. I did omit that piece. We will only display each name once. For displays, we need to work within our existing AngularJS grid structure to display these search results. What I think we'll need to do is have the primary names as column picker options and the preferred names as column picker options as well. This will not only apply to the search results screen, but also to other grids that display patron name information. For the alternate, non-preferred names, we can have multiple alternate names, so it adds complication in being able to display them to the column picker options. We've established a precedent in our alerts project that I think should be used here. If there are non-preferred alternate names, we could have it display a button in the column picker with the number of preferred names. Selecting this button would display the names.
I don't address things sorting in the search results because we will be using the existing web client patron search with no changes beyond the ability to search these other names and to display more fields. The existing sort order is by patron name, and it needs to be primary name since that's the only name guaranteed to be in the record.
I'll also be providing mockups for this interface.
I think I covered everything here. Keep the feedback coming!
> Benjamin, why do you think the downsides of this requirement are?
My concern is for folks whose name has only one part. If someone tells us their prefered name has only one part, then we should honor that. This isn't about someone named John Smith who goes by Jack Smith. Then their prefered name has two parts, Jack and Smith. This is about someone whose prefered name really only has one part: "Shubalanada", "Sumarsam", "Sukarno", or "Everchange". Often this is their legal name as well, which is an argument against requiring a first and last name for the primary name as well, but even if we accept that the primary name must be entered in two parts, it seems desirable to have the prefered name entered the way the patron prefers.
> Patron search results: Yes, you're right. I did omit that piece. We will only display each name once.
Did you mean "We will only display each patron once"? If we only display each name once then we run into the issue of how to handle multiple patrons with the same name. I would expect it to be either "each patron once" or "each name, as many times as it appears". (Currently these last two are equivalent, though with added name fields they will not be.)
Additional thoughts for the Requirements document:
1) The patron should be allowed to add a preferred name in the online patron self-registration form.
2) The process that merges patron accounts should incorporate all alternate names in the merge.
I've incorporated the above suggestions in the requirements document at http://masslnc.org/node/3303/ There is also a diff at http://masslnc.org/node/3303/revisions/view/6397/6441 that is ugly, but will highlight the changes that I made.
1. I maintained the requirement that we require the same fields be submitted for the alternate names. I don't see any way around this if we plan on allowing use of an alternate name in a notice, holds slip, etc. I agree that there are cases where the system should accommodate a name that only has one part. However, I would prefer to find a means to do so for all types of names, not just the alternate names. For example, we may want to implement a method for having overridable required fields in the patron editor.
2. Terran, I added something with the merge patrons, but I want to be clear on what behavior we expect here. Let's say we pick a lead record that does not have alternate names, and the non-lead record has alternate names. Should those alternate names carry over to the lead record? I'm doing the mock-ups now, but I wanted to get the text updates out there for further feedback.
Mock-ups have been added to the requirements page at http://masslnc.org/node/3303/. I have a couple of follow-up comments/questions.
1. We had talked about placing an icon near the patron's primary name in the patron record to indicate if the patron had a non-preferred patron name in the record. Hovering over the icon would display the names. I ultimately went with a text link instead of an icon because I thought it would be more understandable to the user. Hovering over the link should display the alternate names; clicking the link brings the user down to the bottom of the patron sidebar, where the names will be displayed in a way that makes them available for copy/paste.
2. When creating / editing a patron record, staff will need to click a 'New Name' button to add an alternate name (consistent with the method for adding a new address). Initially, I added the 'New Name" button near the primary name fields. However, I was worried it would disrupt the flow of the patron editor form and be an additional thing to tab through when adding patrons who do not require an alternate name. I therefore pushed the button down to the bottom of the form. If anyone has thoughts on the placement of this button, please let me know.
Also, I realized that several people following this thread probably have not seen the new patron editor in the web client, which might be helpful in answering question #2. If you want to see what it looks like, you can go to the MassLNC community demo server at https://mlnc4.noblenet.org/eg/staff. Login is admin / evergreen123. Click the 'Circulation' menu and go to 'Register Patron.'
We're going to be sending these requirements soon, so please send any feedback as soon as possible. I will also be sharing them with the community for feedback.
Visually I find the mockup of the patron search results confusing. In particular, the alternate name view button is not intutivie ("Since there is a possibility that a patron can have multiple alternate names, the alternate name column picker field should display a count of the number of alternate names along with a 'view' button. Clicking the 'view' button should display those names."). This is at least in part because the column in which appears appears to be labeled "Last Name".
Even with a less confusing column label, I'm not sure a view button is nessessary. Why not call the "Alt" column "Alt count" or "Alt name count" and make so hovering over the number of names shows a list of alternative names? Or it could have the functionality originally intended for the view button.
The button is following a precedent that will be used in another development project that will be available in the next release of Evergreen - the copy alerts project. The challenge in that project is similar. When the project is added, copies can contain multiple alerts that we want to make available from the column picker.
Our preference was indeed to show a count that is a link. When clicked, it would bring you to an interface to view the alerts. However, there was a problem with getting this link to work correctly within the constraints of the AngularJS grids we use in the web client. We instead needed to compromise on the button to get the functionality we needed.
I included the button in this project because, although it was not the ideal solution, I feel strongly that we need consistency in the client when we are working with similar elements.
However, in thinking it through further, the difference between the two situations is that the alerts count had a dedicated interface that would be reached by clicking the button. We don't necessarily need an interface for the alternate names. As you mentioned, hovering is all that is necessary. I could incorporate the link with the hovering effect and see if it works better in our grid interfaces.
Alternatively, maybe I should first pose the question of whether we really need a column picker option for the non-preferred alternate names or if we only need it for primary and preferred names. Given the amount of information that a library needs to see in patron search, I would be surprised if a library displayed all of these fields in their grids. Would it be acceptable to say that a library needs to click on a patron and see the details in the vertical summary?
In terms of the labeling of the column, this is something that can be changed at any point in the project. If we decide in testing that the column header doesn't make sense, we can make the change then. My main concern is that the label be short to conserve on space in the gird.
My inclanation is that clicking through to the patron record to see the alternate names is fine, but then I don't work at a busy circulation desk. The folks who do might feel differently.
I would think that circulation staff would be using the grid display to decide which users they need to look at more closely to find a match, not rely on just what's in the grid to decide whether or not to choose the patron record.
I think it would be useful to have a column picker option that displays a count of the alternate names and rely on the left sidebar to display them. This would reinforce always looking at the fuller information in the sidebar before making a choice.
>>2. Terran, I added something with the merge patrons, but I want to be clear on what behavior we expect here. Let's say we pick a lead record that does not have alternate names, and the non-lead record has alternate names. Should those alternate names carry over to the lead record? I'm doing the mock-ups now, but I wanted to get the text updates out there for further feedback.<<
Yes, we would want the alternate names from the non-lead record to carry through.
If the name on the non-lead record has a different name than the lead record, I think it should be added as alternate name as well. (If Jim Smith with alternate name Jamie Smith is merged into lead record James Smith, then both Jim & Jamie should come through as alternate names on the resulting record.)