TOPIC:

First and foremost, wonderful job with the site and support of Toastmasters clubs around the world!!

Is it possible? In the user profile, the admin or member could enter their Pathway. Then when a member is placed as a speaker, instead of it pulling up projects from all eleven paths, it only selects the projects from the member's path. We many times have to correct projects because the member doesn't realize they selected a project from Dynamic Leadership and not their current path.

Kudos to you and your team!!

Some people are working on more than one Pathway, so we would need a flexible approach that keeps that in mind.

Perhaps we could save the last one used by a particular member, which would accomplish the same thing without being overly cumbersome for people who are working on more than one Pathway.

Your thoughts?

I have looked into this a bit more and I think I could implement an option to allow clubs have their members Pathway paths be remembered and used in filtering the project selection drop-down. For example, if you look at the following, when you enter a path name in the filter for the drop-down, what happens is that you just see that path name and its associated projects in the drop-down. You can still ditch the filter and look for a different path/project, but allowing clubs to have the project selection dropdown default to the last path that a particular member selected could be a useful shortcut. Essentially, if the option is enabled, then the code would prefill the filter box with the last path name the member used. This is just my concept at this point, but is something I am mulling over.

Steve, I think people often don't realize that the path needs to be chosen first - hence they just choose the first occurrence of their project which usually is under Dynamic Leadership (which will thus be the "Last path" again the next time).

Would it be possible to have them choose their path from a primary list, and then only allow them to choose a project from that path in a secondary list?

Or alternatively swap the logic and let them choose the project first, and then only show the relevant paths.

The list is not stored as two different things really. It is all one list with categories in it... the categories being the Paths.

Populating the filter with the members previous selection sounds like an effective way to accomplish this. If a member wants to move to another Pathway or project, clearing the filter could restore the 'collapse all' view which leads to the next thought...

I think Pam's 2nd question would be accomplished by initially opening the dropdown list in the 'collapse all' view. I think this would be very helpful. Trying to teach members to always collapse all is avoided and those who are more comfortable poking around can expand all.

Another way to help members sort the list would be a row of buttons to filter the levels. Same results as putting L1 or L3 (etc) in the filter box. Perhaps bordering on overkill but using the levels in the filter box maybe isn't very intuitive.

In practice it would look like this:
Open the project dropdown list (default display is the collapsed view)
Click a level button at the top of the dialog box
Expand the desired Pathway
Only the selected level is visible

What a lot of people do not seem to realize is that the filter works by hiding stuff that does not contain the entered text. Another way to look at this is that everything must be displayed prior to applying the filter... everything including the group names (the paths) and the various options (the projects).

This is baked into how the enhanced multiselect widget works. Therefore, if we open the widget with everything collapsed, you essentially will cause the filter to only work on the group names (the paths) which is what is shown. This is why I have been resisting the several calls to open the widget in collapsed mode--it essentially degrades the filtering functionality.

Yes, I did do some of the development on the updated widget myself several years ago. However, I am not the original developer of the widget, and I really do not want to mess around with its complicated internals anymore. I wasted way too much time on that the last time I did that.

Besides, I want to eventually reimplement the FTH UI using vue.js and the widget will not work w/ vue.js as is... It would need to be redone w/ vue.js. Vue.js is going to be a very heavy lift for me.

Got it, that makes sense. "everything must be displayed prior to applying the filter" I appreciate the filtering explanation!