Sean and Danny were talking about demos and techniques. They are prepping an outline with hyperlinks to help them navigate and show things quickly vs having to navigate the whole system to get to the same pages. Good technique.

Steve joined the meeting, even though it was his day off. We got into talking about new time settings and my meeting yesterday with Beaver Mountain (local ski school). They have been using adilas for close to 7 years now. Most recently, they are looking to use it to help them with registration for their special mountain events and races. It was unintentional, but I ended up giving all of the guys on a meeting a full-on demo of what we are doing and where we are heading.

Steve was kind of challenging me on a few things - why did you do that? What about this or that? Maybe we could do this or that, etc. We talked about it and I took some notes. I still don't fully know what direction to go and what would be best, but I took some notes. Some of it was dealing with multiple systems vs a single system, settings, custom code vs building for the masses, and individual customer records vs quick flex grid to get super simple data into the system quickly. We talked about effort levels, timing, speed, data in/out, exports, and future flow. It was a good discussion, even though I felt like I was being challenged on every front.

As a side note, when we started this project, back in 2015, we didn't have what we have now (7 years later). If we had had what we have now, it would have been a different story. All things are possible and are options, it just depends on timing, resources, budgets, skills, and where the system is at (functionality wise).

As a part of fracture and going forward, we will be trying to turn in as much stuff to settings as we possibly can. We have 4 known levels for settings. They are corp-wide (world level), group-wide (12 main players), page-wide (per page per section), and user-wide (preferences and options per person). Things keep breaking down into smaller and smaller pieces another word for it is "subs". We even were talking about things like subs of corp-wide settings and almost location-wide settings. We don't want to go there yet, but it is starting to surface. Basically, the main goal is to turn everything into settings, where possible.

Along those same lines, if you have tons of settings, you will also need different levels of users - end users (lower levels of knowledge and skill), medium or middle users (knowledge of settings, options, and configurations). You will also need the admin users or backend/systems admin persons (who is making and building the settings for the others to use). It can get deep.

It is ok to re-think the processes or re-think these processes. Permission granted! Often, education leads to new ideas. We see it in our clients all the time. We add something or teach them how to do something and almost immediately they come up with something new, different, or that now seems possible based on the last known level. We call that taking the next logical step. It's huge and big part of what we do.

The last note for this session was this - everything is breaking into subs, sub settings, sub permissions, and sub configuration options. Everything!