Course-Related Activities website architecture change
Course-Related Activities need to be connected with the pertinent Course offering. (i.e. Course-Related Activities should NOT be connected to the generic Course Template and thereby connected to all offerings of Courses based on that Template).
With the current setup, the process for creating an instance of a Course is to start with the pertinent Course Template. The Course is then filled out with more detail by creating Course-Related Activities (such as lectures, field trips, etc), which are at specific locations at specific dates / times.
It is important for each unique offering of a Course to have its own unique Course-Related Activities associated with it. However, the website system is NOT set up that way. Instead, the Course-Related Activities are tied to the COURSE TEMPLATE.
This creates enormous problems in situations where two or more instances of a Course are posted that overlap each other. For example, consider an instructor looking to register to instruct at one field trip. Their search for the course will yield a confusing display of ALL open instances of the Course (and also ALL open instances of ALL field trips of ALL open Courses) associated with that Course Template. The field trips for different courses are displayed co-mingled with each other. Instructors get confused – some take the extra step to select the specific field trip and register (which works) but some inadvertently register for the entire Course, which enrolls them in ALL field trips.
As a result, rosters of separate field trips get co-mingled with each other, and it is difficult-to-impossible for a field trip leader to disentangle rosters and have an accurate record of which instructors are registered for which field trips. This is unsatisfactory and makes it nearly impossible to coordinate field trips.
Even worse, the result at the end of the Course is it is nearly impossible to tell from the online rosters which individuals participated in which Course-Related Activities. For students of the Courses, it can be nearly impossible to tell which students have satisfied the requirements of the Course.
This situation is unsatisfactory and un-workable.
The fix would be to tie Course-Related Activities to the pertinent instance of the COURSE. Re-structure the architecture of the website so Course-Related Activities are NOT tied to the generic COURSE TEMPLATE.
The fix needs to be soon, while the records are still new enough that there has generally only been one offering of each course. If the fix were delayed to a time at which point there have been multiple offerings of courses, it would be difficult-to-impossible to derive which participants have been part of which Course-Related Activities and verify which participants have satisfied all the requirements for their respective Course.
We had a chance to discuss our course architecture in depth on June 9 in Everett and how to best utilize the structure we have to avoid almost all of the problems listed in this thread. The one item we are working on for fall is having a single seminar style course type which is much more activity like in nature but has an instructional component to handle special instructor clinics and workshops that we often offer in The Mountaineers. We hope to meet again with Everett leaders in the fall to help schedule courses and make sure that everyone understands the most efficient way to set up and manage courses and the activities that go with them.
If you’d like to know more about or comment on the single activity course please comment here: http://feedback.mountaineers.org/forums/273688-general-feedback/suggestions/6836270-create-a-new-course-content-type-better-suited-for
Sorry, this was NOT completed. I've extended a lot effort to describe shortcomings of the current architecture and to propose an easy improvement. The issue was closed after a discussion where I was not present where a few "workarounds" were presented. The issue was not fixed, all of the deficiencies remain, and the solution amounts to a burden on Everett Branch to better train their members overlook the issues or work harder to circumvent them with bad practices.
I wish I could have been there to defend my position. I have over 20 years of experience with data designs and I know with certainty the current design will be an endless source of confusion, work-arounds, and date logic tweaks to compensate for the missing relationship between an activity and the course to which it belongs.
The sad part is that the fix is relatively minor, is backwards compatible, adds data value, and, if completed soon, costs less than all the circumventions.
Please tell me, what are the workarounds for this:
When I look up the 2015 course today, no lectures or field trips show up under Course Requirements. When I look up the same course later, suddenly it shows the Course Requirments that belong to the 2016 Course.
Just one more thing.
Specifying the course offering instead of the course template when we schedule a course-related activity is a value-added proposition and is 100% backward compatible to the way the website works now. In other words, if we assign the course offering the system can easily derive the parent template. But not the other way around.
A this is a small, forward thinking change that requires a minor development effort now. It creates the foundation for future enhancements that are otherwise not possible without considerable expense. Seems like a wise investment to me, even if all the benefits aren't forthcoming for awhile.
This is a very important concern that not only affects the usability of the system, it affects the integrity of the historical data, specifically: which activities belong to which courses.
On a course page, there is a tab for "Course Requirements" that lists lectures and field trips. But what it really shows is "Future Lectures and Field Trips similar to those in your course. Activities from your course disappear when they are past and future activities from other courses (under the same template) are inter-mingled.
We want the Course page to show all lectures and field trips for the course (even if they are past) and no lectures and field trips from other courses.
I've been told this design is intentional to make it more convenient for courses that last several years, like Intermediate Climbing. Without pressing the point, is it really sensible to compromise the website for most of us in order to accommodate the few? Besides, I contend that we can have our cake and eat it, too. Here are a couple ways:
1. Add an option in the course template for showing the activities across course offerings (up to ? years)
2. Separate activities explicitly assigned to a course from those of other courses in a different tab or section.
You cannot tell what activities comprise the course. The system does have that information because it is not collected when the activities are scheduled.
Probably the most insidious side-effect occurs when multiple courses have required field trips, When the student registers for one course, the system automatically registers the student for all required field trips, even those for the other course. The system cannot tell which field trips go with which course.
The rebuttal I've heard a couple times is that the system was intentionally designed to show activities for multiple courses because some courses take multiple years to complete. The idea being to facilitate signup for activities in later years. That's just not sound reasoning and I want to explain why.
First, there are relatively few multiple-year courses. So, even if it it comes down to a choice, of which kind of course to support best, it doesn't seem right to compromise the integrity of all courses for the benefit of such a small few.
Second, I submit we've been presented a false choice. My suggestion is not about what activities students may sign up for. My suggestion is about keeping track of which activities belong to which courses. And truth-be-told, "knowing" which activities belong to which courses not only makes the system more capable for shorter courses, it's a more robust design for facilitating activity signups across the longer courses.
Said another way, if we know the scheduled course for an activity and we know the course template for the scheduled course, then we know the course template for the activity. That's the same information (plus more) than we have in the current design. Consequently, the system can do everything the system does now, plus more. The "plus more", is a long list of features that I identified in the original suggestion.
Finally, I want to point out another weakness of the current design. Suppose a 2014 course is based on 4 field trips and in 2015 the another field trip is added. In the design now, that means both courses have 4+5=9 field trips (and it gets worse as history accumulates). The 2014 student may then sign up for an activity that was not part of the 2014 course! How weird is that? A better design is allowing 2014 students to signup up for other year's activities having the same activity templates as those in the 2014 course. But that's only possible we you know which activities belong to the 2014 course. And that's the essence of my suggestion: track which activities belong to which scheduled course.
In case I didn't explain it well, this problem does not manifest until a course template has activity history for more than one (year's) course.. Since the migration did not create activity history, the issue is not highly visible yet. By next fall, when the second round of course history begins to show up, the problem will be painfully obvious. Unfortunately, what is relatively easy to fix now (precisely because we do not yet have much history from past courses) will be prohibitively expensive to fix (because we do).
Here;s an example of the 2014 Everett Nav Course which has one activity, but the system is confused and shows no activities:
Here's an example of the 2009 Instructor Workshop that lists the 2015 workshop as an activity. Not if there were 10 year's history, the 2009 workshop would list activities for all 10 years.
Here's an example:
2014 Alpine Scramble Course listing activities for the 2015 course.