It would be helpful to have an equipment list area inside Scoutbook to use for checking out/In equipment. We can use Excel, or other spreadsheets, but those are not contained within Scoutbook. Having an option inside Scoutbook would help keep everything we need in one place. Any thoughts if something like this is possible? Troop level, Trailer level, Patrol level sheets would be awesome.
YIS
Jerry
Hi, @JerryFahrbach,
We use a Google sheet to track this stuff. I suspect anything configurable enough to be desirable would be difficult to implement. You could, for example, use your unit forum on Scoutbook to host links to the relevant Google sheets.
@JerryFahrbach - I understand the want but the implementation would be interesting. Just thinking of the troop I belonged to it was primarily a backpack troop. There was little troop gear. Then you have the multiple trailer troop. Hard to make a universal fit for all units.
While always qualifying any feature request as TBD on value relative to an unknown amount of implementation effort, I could see this as quite useful. Our pack has tents and a few other items that could use this function.
A minimum viable product could simply be a single table that lists an inventory number (e.g. 000001), choice from a second table of category (e.g. tent, dutch oven), a description (string) and a condition (string), secondary key of the person (if any) that has checked it out and check-out date. Then you’d just run a query to display the current status of all inventory on a new page, a query using the user to show on a user page what equipment they have, and then a quartermaster function to push record changes to check in and out.
I don’t know that an online database would be a better option than a clipboard in the troop trailer or equipment locker.
There’s nothing wrong with tracking things on paper, but we track it online via a different system, and it’s a huge help. Often we want to know who had what item at varying meetings, and it’s a great reference.
Based on the number of calls for “custom” awards and event types that have received the BSA’s thumbs-down, I’m not sure how readily the BSA would adopt adding in an inventory system. A support/maintenance issue I can see arising is requests for “custom” categories, and custom fields. I’m not sure that represents a major implementation/maintenance issue if implemented from the outset, but I’m also not familiar enough with the programming side to be sure.
Also, what level of storage space might this require, if every unit moved over to using Scoutbook as their QM inventory system? I don’t know that it’s a significant number, but I imagine it’s non-zero, particularly if old items are not purged, just marked as “discarded”.
I’m not arguing against it, per se, since I think it would be a useful addition. I’m trying to better understand what level of implementation and maintenance/support/overhead “costs” we’re asking for.
It is great to have all of these grand ideas of how to make scoutbook the catch all of unit function up to and including I suppose Pinewood Derby racing, but does anyone consider storage, processing, and maintenance. These are all factors that need to be considered.
I think generally this forum is intended to identify requests and let the developers assess the effort. While I have tech background and believe this one would be relatively less effort than some of the requests, only the developers know how it would apply to them. I think this one would be useful, but I too wouldn’t say it would be at the very top of my list.
Why don’t we use this forum to describe the features requested in as much detail as we can so the developers can assess the amount of effort to implement. Then we can also indicate priority in our own book, and then the developers can decide what to do. I’m getting this as helpful but not earth-shattering.
My question was more aimed at the fact that I know some people here have knowledge in the correct technical fields and could share it with the rest of us (like me) on the strictly-user side so we can evaluate whether or not we’re asking for something unreasonable before we add it to the list. I’m probably more techy than average, being an engineer who likes to mess around with 'nix systems, but I’m far from a professional in the infosys/database fields. The more I learn, the smarter I get about what to ask for and how to formulate the desired set of features to make it more practically implemented.
Of course, I recognize that the professionals from the BSA will ultimately be the ones making the call as to whether or not it gets implemented. It’s just not clear what pathway from this message board to the planned features list these types of requests take and how they are evaluated.
I see new feature requests the same way I suggest my scouts look at event planning. There’s no reason to automatically assume we can’t do a long trip to Hawaii from California, but the scouts planning such a trip need to contemplate costs, lead time, risks, etc at least somewhat before they bring the idea to the adults for any kind of review. Otherwise, it’s likely to get kicked back for additional planning. Similarly, there’s no reason, per se, not to request that file storage be added to the system for units to maintain unit-level documents. However, given an understanding of the costs to implement and maintain such a thing, more units may decide to pursue an alternate path and throw their weight behind advocating other tasks. At the same time, if it’s important enough to enough people, those people may start a funding campaign to help BSA pay for the added storage/overhead/etc associated with such a cloud system. If everything is viewed as the same level of cost (whether measured in programming hours, maintenance/overhead costs, server space, etc), then I think it’s hard for a lot of folks without the relevant technical background to understand why one request that doesn’t seem too difficult on its face could be a huge undertaking.
I understand the viewpoint that we just ask for features and assign a priority. I’m hoping to educate the user base a bit more as we go along so we all better understand what we’re asking about.
Things to think about with requests that add to the database.
I’m very familiar with storage pricing, and even for high-availability systems, the cost actually would be negligible for this very limited plain text info. If photos are used across all the user-base, it could be an issue. Certainly this is something that the developers could estimate based upon which clouds they’re running.
Charley, I think it’s reasonable for those of us who are in tech spaces to share what we know and estimate whether this is like flying to the moon vs walking to the end of the block, but my take is that we ruin this forum if we get too deep in shooting stuff down if the developers of this actual system aren’t participating on the board.
Let’s just try to land on helping the developers understand each request, help each other flesh it out and make it as great as possible, and weigh in on what we believe the importance of the request would be. That way, if there’s broad agreement that there are some high priority items, developers can look at those and knock some off and still have the opportunity to consider some lower priority items. Only they will be able to assess exactly how hard it is. In some case, developers might rearchitect something and see that they could incorporate a low-priority upgrade because they already were re-doing a component.
The other thing to watch for is exactly matching what the other unit management tools offer. For many units they will likely stay where they are as it is within their comfort zone and matches their needs. Scoutbook should not end up looking like troopmaster, troopwebhost etc.
I’m in agreement that a GoogleDoc or Excel Online are equally good options. I say this as my troop asked me to do something similar and I ran in to issues where everyone wanted something different based on their perspective of how the program should work.
TBH, Google Sheets / Excel Online (they are both equally good) are great ways to compensate for basic trackers. In addition to inventory tracking, having one to track cooking/meals (for cooking merit badge) is another I’m about to start, as are carpooling planning, summer camp planning, etc.
I agree that while it would be cool to have in ScoutBook and on the surface relatively simple to do, it can get complex (meaning expensive) very quickly as people start asking for things like reminders, custom ways to track inventory condition, etc.
Now that the new Forums are up and running, we’re putting links to all of those documents in our troop forum. PLC worksheets, inventory, blank duty rosters for camp outs, etc.
That really makes up for one of the gaps we saw in Scoutbook when we migrated over from Scoutlander—the lack of online storage. The new forums even do a pretty nice job with photos.
+1. For our Troop I have a OneDrive where we put everything including Hike Plans, Cooking MB templates, Troop Committee Meeting meeting notes, etc. Word Online is awesome.
Then in ScoutBook we simply link to these documents.
That said, I do find GoogleSheets easier to set up and use than Excel Online, but TBH they are functionally equivalent so it’s really a personal preference.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
© 2019 Boy Scouts of America - All Rights Reserved
