I understand that you are replacing Scoutbook.com with enhanced IA2 functionality, to modernize the system. However this is especially painful because Scoutbook.com was developed by an end user, and was therefore a user-centric tool. For all the talk of enhanced architecture, your architecture can’t create or result in effective user-centric design, if the design is lacking sufficient input from actual users… Do you have end users involved in design requirements, user stories, testing or signoffs? Users who are actually using this tool to enter actual Service, Hiking or Camping activities?
I must say that you are lucky that due to COVID there are less activities being entered in right now. My bet is that there would be significant uproar right now had so many summer camps and activities not been cancelled! Leaders would be trying to enter activities, and doing it correctly, but not obtaining the intended result due to system design issues and bugs.
I just spent several more hours entering 20+ nights of Camping, 20+ miles of Hiking, and Service hours, all from over the course of the past 2 years. Several issues I highlighted about two months ago are resolved, but other major items seem to still be present Here is my previous post on similar issues. I know that my use case is not the ideal use case, but nevertheless it has shed light on a number of issues:
Page loading takes FOREVER Whether accessing through the Scouting App, or the IA2 website, even on a high speed connection, page loads are slow. It seems to be a data load or a database issue. (I would not want to try the app over cellular.) You hide it a little by having the screen paint early, but the data lags several seconds prior to loading. This is also evident when you make an addition to the log, as the success message loads, and then you need to wait several seconds for the screen to redraw.
Calendar loading takes a long time Similar to above, when you click the plus icon to add a Campout, Service, or Hiking activity to the Activity Log, the calendar spins for several seconds, as the calendar checks to see whether there are any activities on the Calendar today. I believe this is another manifestation of the database issue above. Presumably it is checking the current date to see whether there are any activities on the calendar. However, even if there are no items on the Calendar, the page takes a long time to load, which would indicate a database response time issue, not data load time.
State entry under Address To enter the State for the Address of an activity (same for Camping, Hiking or Service) text entry is not allowed. You can use the mouse to select, or you can Tab then up or down arrow and then Enter. I should be able to press the first letter of the state name or abbreviation and have it scroll to the item. Page Up and Page Down also do not work in the scroll box. I admit that my state is near the end of the list, but even when I lived in Connecticut, I would enter the state by tapping the C key three times (California, Colorado, Connecticut …) Please save me from carpal tunnel syndrome and make your input KEYBOARD FRIENDLY.
Calendar Start Date issue Text entry is allowed for the Start Date, however it is a non-standard date format, The Date format used in the Activity Logs is a non-standard date format. It is MM(space)(slash)(space)DD(space)(slash)(space)YYYY. Why? What kind of date format is that??? For the sake of those of us who prefer keyboard rather than mouse entry, can you please use a standard format?
Once I figured out the non-standard date format, I am now able to successfully enter a Start Date by typing. I acknowledge that I am in the process of entering data for youth who recently transferred to my troop, so I am entering activities from the past. As you can never assign participants to future activities (a design decision I agree with) I imagine that entry of past activities will continue.
P.S. As you made it so (for now) IA2 Activities cannot be deleted (huh?) there are several leaders who have now been conditioned to not enter activities in IA2 until AFTER the avctivities have already occurred.
Calendar End Date issues Text entry doesn’t seem to work in this field, neither through typing the dates nor copy and paste in this field. They do not work. You must use the mouse to browse to the appropriate date and click it. (see item below on recommendation for different default END date)
Calendar End Date Entry Default Date
I would request (strongly) that you make the default date for the End Date box be the same date as the Start Date, rather than the present date
This box does not work consistently. My guess is that you are doing some sort of DB call in the midst of the entry here. Pressing Tab after entering a value here does not register the value at all, ever. (In contrast, the address field entries commit with Tab.) Sometimes I click the next address field and must click back on this field or I will have a blank under Location. In order to commit the Location value, the ENTER key usually works. However, sometimes I need to hit ENTER multiple times. It seems there is some data load operation taking place and it lags sometimes. The end result is that I usually need to enter my value twice, or enter it, then select it, which is dual entry.
Wrong Dates - what time zone are you trying to force events to be in? CDT? WHY?
This is still a MAJOR issue, and it cascades into all sorts of unintended consequences, such as campouts longer than they actually were, or on the wrong days. The end result is that I need to enter the date both when I create the activity, and again when I am assigning scouts and leaders as participants. (Dual entry … user-centric design will avoid that)
I can tell that you still have the same issue in the Service Log, even though you only ask for a date, without a time. In the back end on the Service activities, that you are assuming an All-Day Event, but once registered in the database, it shows up as an event that was normalized to central standard or central daylight time.
There should NOT be a time zone. The only relevant time zone is the zone where the Key 3 are entering the item. Something in the database is trying to translate and resolve the dates and times into Central Time Zone. JUST STOP. PLEASE. IT IS CAUSING ISSUES!
If I use the ALL DAY Event, then it assumed a 12am -11:59am Central schedule for my activity. It therefore makes my Mountain Time Zone activities begin ONE DAY SOONER. It makes all one night campouts count for two nights.
If I don’t select the ALL DAY, but enter actual start and end times, when the activity is committed to the database, the interface displays it back to me IN CENTRAL TIME (huh?) one hour earlier than everything happened.
WHY HAVE A TIME ZONE AT ALL? Don’t query my computer for what time it is or what time zone I am in. IT DOESN’T MATTER WHAT MY TIME ZONE IS. All times for Activities should be absolute. Fine if you want to mark it as CST or CDT for the sake of the database, but then assume that my local time is also the same CST or CDT and there is no need for any date/time translation. I get you want to use notification with calendar items, but then take into account my system time or the time zone with EVERYTHING THAT IS DONE FOR MY TROOP AND ACTIVITIES. If you are going to translate, make sure you can UN-translate it. It is not like my troop and the chartering organization are going to move. You could use a fixed value for my troop time zone offset … so if you need time zone, DO IT RIGHT FROM THE USER PERSPECTIVE, and make it consistent.
EVERY TIME I create an activity, I need to edit it when I am adding participants because of your failed attempts at time zone translation.
Date for specific items in the Activity Log should be ACTIVITY DATE not APPROVED DATE
When I am reviewing the details in an Activity Log for a Scout, you are displaying the APPROVED DATE for the Service, Hiking or Camping activity. In the History, please display the Start Date, or Display both Start and End Date. Once approved, the approval date is irrelevant. In the example below, you can see from my title that these campouts happened at different times, but the approval date is not helpful here.