Welcome! This forum has a treasure trove of great info – Scouters helping Scouters! Just a heads up, though - all content, information, and opinions shared on this forum are those of the author, not the BSA.
When trying to find a parent in the search option at the time of adding a parent to a new Scout (A.K.A. connection), I notice that if I search for a common name, and get multiple results back, I can’t easily tell if the right “parent” is in the list. Sure it lists their names and it gives a description with their ‘Local Council’, but sometimes that just not enough information to know it’s the right person.
This creates multiple potential problems.
Problem 1: If it turns out it’s the right name, but the wrong person, when I submit the update, the wrong person will get an email indicating they’ve been connected with the scout.
Problem 2: It’s not until the connection has been made, between the “parent” and the scout, that I can look at the connected parent’s profile to determine if I’ve connected the right person.
Problem 3: The search option only works part of the time. Because I’ve searched for common names and gotten multiples, and I can’t tell who’s who. I’ve taken it upon myself to find the parents email address and search by this. Searching by email only gets a hit about 50% of the time. What’s more, I can put in a partial email address and I’ll get a hit, but while the real-time results filter in, one slow character at a time, it’ll eventually cause the results to go blank, even though I did see the person I was looking for a second earlier. This is likely because their email address contains their name and it shows a result only until the filter reaches the @ symbol and then all bets are off.
Feature Request 1:: Be able to view the profile of the searched results to ensure you have the right person before connecting them to the scout. I think this could eliminate all of the issues I’ve described above.
Feature Request 2: Search for parents in a general search filtered to the Pack. If we’ve already entered the parents info in Scoutbook, we should be able to search for the parent first, then connect them to the scout(s) they are a parent or a leader of. Going to the Scout account first is very un-intuitive.
I’m not sure why the email search option has become so slow. It used to be both fairly quick and robust. That said, I entered the full email address for several of the adults in our troop, both those with “odd” email addresses and those whose address includes part or all of their names. I had to wait a while (1-2 minutes each), but every one of them returned a unique account.
Regarding Request #1, this would expose personally-identifying information to everyone who has access to search when adding a connection, which includes parents. There are already complaints about the fact that an erroneous connection would expose that data. To avoid problems, I suspect one would at best be able to expose a portion of the address (e.g. street, city, state). That could be an improvement, but as city and state are already displayed, I suspect it’s not much of an improvement, since I’ve often seen adult accounts missing all street address data.
Regarding Request #2, I don’t believe that non-leader adults are associated with a unit until they are associated with a scout.
@MatthewHarms - I know you are concerned about the addition of parents to new scouts. I would think that the search for parents new to the unit would not be a productive search as they are …well new and not in the database. In the off chance that they are in the system then using the email should be the best option as folks should have unique email addresses.
Hi Stephen. I totally agree, but when I’ve performed the 4 searches, by email address earlier today, 2 of the 4 (50%) showed up. I was able to confirm that the other two that didn’t show up were correct and were a record already in Scoutbook, but for some reason it still couldn’t find them.
HI Charley,
In response to your #1 response, I totally agree with keeping PII protected. I work in IT Security, so I completely understand the need to keep this information secure. I go to ridiculous measures to ensure the safety of my families PII and yearly my information is compromised by big businesses, so I can appreciate the need for this reason. This is also the same reason I mention that the search should be filtered down to our Pack when revealing additional information. I don’t so much care about those people that aren’t in our den, unless I need to add a new, existing parent or one that’s recently moved but their record hasn’t been updated. But beyond that, as a Pack Admin, it is one of my responsibilities to make the connections in Scoutbook and providing a whole list of like named people isn’t helpful. In fact it’s just a distraction. While I don’t disagree with the point about exposing PII on the Parent’s record, the truth is, they’ve provided their information to be used in this fashion by submitting their registration papers. What’s more, all of the kids information is in Scoutbook and that’s fully accessible, printable, etc, so I don’t see much of a difference. I do like your idea of providing a street, city, state in the results as this would at least prove to be a tad bit more useful. I think having just a fraction of their email address would prove to be way more useful since again those tend to be more unique.
Addressing the response to #2, this is where I feel that not only should the Leaders and Scouts be listed on the Pack page, but the parents should be listed too. Not exposed to everyone, just those that have the rights to perform the admin work. Right now there’s only the two sections for Leaders and Scouts, but a third section listing the parents would be useful.
It just kind of scares me that Scoutbook’s willing to compromise our kids identity security but if it’s the parents then we’re more concerned. That doesn’t make sense. It should all be handled carefully. And with the right permissions, it can be. I’m not suggesting you’re saying this Charley, I’m simply indicating that this is how Scoutbook operates. Implement the right solutions, not the half concocted solutions.
As for the searching capabilites, I just notice that I can type in a name (i.e. John) and it literally processes each name in it’s database, filtering out all of them that start with J, then with Jo, then with Joh, and finally with John. Each time the results will print for about 2 seconds before it attempts the next letter in the name. This is the painfully slow response Being a amateur programmer, and working with professional programmers, I’ve seen this sort of behavior in other poorly programmed applications. I’ve even sat on change review boards that discuss this exact type of behavior and the solution has always been to have the code wait until there’s a few seconds of idle time before the responsive query kicks in. Heck, for any of you who use Netflix or other streaming services, you’ll see this exact sort of behavior there in their searches as well. This doesn’t solve the inefficient search algorithm that’s being used behind the scenes. That is usually corrected with indexing a portion of the records. For any DBAs who might read this, they’ll know what I’m talking about and could easily speak to this much better than I can.
Anyway, I digress. As I’ve said before in my other posts, I really want Scoutbook to be the best it can be. If I didn’t care, I’d just trudge along and use it without saying anything or find a different solution. I know it can be better but we need solutions to these problems, not just limp along with a half implemented concoction.
The biggest problem is that the software as originally implemented was developed not by the BSA for all units, but by an individual for their unit. They expanded it from a pack application to a troop application. They opened it up to other units, and eventually the BSA bought it. It was never architected to expand to handle enterprise-level demands. That’s not an excuse, per se, just an acknowledgment of the role that development history played in the evolution to where we are now. I wish the BSA had fixed some of these types of issues (permissions! calendar!) before they released it to the world at large. Now that it’s in the wild, though, the question becomes whether to create a new problem to solve an existing one (e.g. intentionally expose all of the adults’ PII to anyone looking in order to make it harder to accidentally expose the youths’ PII), or to take the time to get the solution right instead of sprinting to the next buggy implementation.
I do disagree that the BSA believes that there is less of an issue with the youth’s PII being exposed, though. In fact, the adults’ PII is just as exposed when they accept the connection (although someone else pointed out that the information at least was exposed as soon as the connection was created). Anyone with the right (wrong?) permission sets in the unit can then see the adults’ PII. Like everything else relies on the volunteers to vet the data, and not to peek through our neighbors’ windows. It’s a less than adequate approach, I agree.
Adding search by email address was a big improvement, and is the BSA’s stopgap, as far as I can tell, while they rewrite a large portion of the back end structure to migrate what was a reasonable solution for small numbers of people to more of what they need for this large and diverse a group of users.
I don’t agree with this. I doubt even one of the parents in my unit would agree that they consented to someone from another unit viewing their PII, even in the ostensible interests of protecting the youth’s PII. Most of them would have to get an explanation about why anyone other than someone from our unit (even database admins, registrar, etc) would see their PII. I think most if not all would agree that they submitted it so it could be associated with their scout.
I’ve always thought that live search result guessing was a waste. It looks cool if you’ve got flops to waste I suppose, but I’d rather that they implement a fast, accurate search algorithm, return the results in a timely fashion, and let me sort out what the right answer is if the algorithm can’t identify a unique answer. If I can wait for a scout to mumble his way through the Outdoor Code, I can wait for a search to return. I agree that we need more data exposed to make it clear we’re offering the connection to the right adult, but it has to be a limited subset.
I agree that would be more helpful, but still not sufficient to eliminate all issues. Honestly, though, it seems like the right solution if we’re going to use partial email as a verification tag is actually to reimplement the search algorithm, or at least the partial indexing, so searching by email works efficiently. We know that has to be unique, per the way Scoutbook appears to vet the new account creation.
I’m not sure logically why one would associate a non-leader adult with a unit (in a database sense), except in relation to their youth. The only relationship a non-leader adult has with a unit is via their scout. It seems like adding a relationship between a non-leader adult and the unit would just be an extra piece of data vulnerable to corruption and requiring integrity checks. It just seems like one more relationship between records to manage, especially if they have youth in more than one unit at a time. Maybe this is already done behind the scenes once the adult is connected to the scout, and they automatically inherit the unit from their scout’s record?
I think at the root of it all, we’re violently agreeing that the software needs work, some parts more than others. Unfortunately (or maybe fortunately), the BSA doesn’t really seem to be taking a headcount to see which features/bugs are most important. After all, I’m way less interested in getting a market-driven number of cupholders in my car than I am in crashworthiness.
I’ve brought up a request for awhile of having the BSA MemberID show up in the search results, and to be able to search by the BSA MemberID. Another thing that would be beneficial is to have ALL of the search results displayed rather than just 10. I have some names that I know are in the system, but I can’t get to them because there are more than 10…
Perfect. Thanks for that reminder. I completely forgot that was an option. I think it would make more sense for those options to be on screen instead of hidden away, but that’s another feature request topic for another day. Thanks Jacob.
They are in SB with the same email I searched for. One of them is my wife and she is connected with one of my son’s but when I went to connect her to my other son, with the same email address, it couldnt find her. I searched by name and found her, but again I like to be sure I’m selecting the right person before saving/submitting and again the results don’t ensure I’m selecting the right person. I went ahead and added my wife’s connection anyway so that part is done.
Thanks Charley for being so thorough in your replies. I’m happy when people can debate on topics and bring their own point of views to the table. It helps me think differently and more critically about my initial stance on a topic, so thanks for you feedback. At the end of the day, I have no real impact on how the SB devs operate but I hope this conversation gets their attention and helps guide their future decisions.
Thanks to everyone who has or will continue to chime in on this topic. Thanks to the SB devs for what they do.
Just off the top of my head maybe another way would be to submit a “friend request” of sorts so you have to get the permission of the adult you’re trying to manage so that you can add the coonections between them and their kids or Scouts. Ive not invested any more thought into that concept so I’m not sure it would solve most issues or introduce even more. Just spit-balling here.
I agree that we need more data exposed to make it clear we’re offering the connection to the right adult, but it has to be a limited subset.
