Chuck is currently working on the add/edit elements of time page. It is pretty big and pretty dynamic with lots of possible combos and show/hide scenarios based on time template settings. He is doing a snow owl (theme) facelift on the page. We also talked about a number of other fun topics.

- Chuck recommended, for fracture, what about preset color pallets vs full custom colors. We may need both options (presets and build your own custom look and feel color pallets). See a screenshot for a picture to see what WordPress does for preset color pallets. Trying to get ideas.

- As a side note, we currently are revamping things to show different visual displays for the snow owl and classic themes. Lots and lots of extra code and it may eventually effect load and run times. On average, Chuck was saying that we end up with almost triple the amount of code, going from an older original file (just classic) to showing both classic and snow owl theme options. That also translates to more code to maintain and keep updated. Lots of moving parts. When we do the fracture project, we want to make it standalone product. Basically, the old code will support classic and snow owl themes but fracture will only support the new fracture options. Simplify the code that needs to be maintained.

- We talked about using more content and page loaders - using asynchronous loading and asynchronous processes. We also talked about big reports and either using in-line asynchronous loading or doing some kind of build report to file type process. Especially for big or huge files (over 500+ records at a time - say 1,000, 10,000, or up into the 100,000+ records - we have some reports that could output millions of records). If we do a asynchronous process or build to file, we will also need notifiers, emails, text messages, or some other type of push/pull type communication. This may be a nice feature for fracture and future development.

- Going along with the huge reports and data tables, mentioned above - for fracture, we may want to build in the BI (business intelligence) levels and have sums, averages, counts, and other aggregate values right from the start. Sometimes we have users pull 10,000+ records, just to get counts and totals. Let's help that data (the BI level) rise to the top and be available so that we don't have to output and show all 10,000+ records. They may only want the aggregate values anyway. If they want more info, we could allow stepped drill-downs by month, week, day, items, categories, or some other grouping. That will help the record counts be much smaller unless they really want to see all of that data. Once again, we could do the asynchronous or build report to file type process for super huge reports.

- As long as we are talking counts, sums, averages, maxes, mins, and other aggregates for fracture - we really need to think about adding in visual homepages or graphical homepages with dashboards and other quick data references. The details are great, but that is only one of many possible views. We could use calendar views, timeslots views, horizontal grids, vertical grids, grouped reports, details, and other fun dashboard type interfaces. This could include charts, graphs, quick counts, trends, etc. Once again, at the BI level (business intelligence) on showing the data. Allow for drill-downs, filtering, exporting, saving reports, or refining a search if something different is needed. Quick access to the data.

- Push and pull communications - push notification is we (the system) pushed the notification out to the user or group of users (text, email, phone call, browser message or prompt). Pull notification is, you, as a user, requests or pulls certain types of information. Currently, our most common form of communication is pull notifications. When building out fracture, we would really like to be able to define more options for push and pull notification and communication channels.

- We circled back around and were talking about survey's, market research, and asking for feedback before we build the fracture project. As a side note, there really needs to be a plan and then help everybody build towards that plan.

- As part of the plan for fracture, we really want to build out a style guide and get the primary elements in place before anybody else builds the other pieces of the plan. We want it to be consistent, all the way through the build and deployment process. Everybody who then works on the fracture project would be expected to follow suite and follow those plans, guidelines, and style guides.

- Chuck and I talked about checking out competitors and their pricing and then building some marketing based on that research. As we were looking around, some of the other products out there have a smaller starting price but then you have to add on tons of modules or multiple by locations and by seats (active users). We want to pitch the whole thing as a package and then make it so configurable that it could appear small, medium, large, or extra-large. It's all done by settings, permissions, and configurations. Anyways, we really could use some more market information and data before building out fracture.

- Eventually, the fracture part of adilas will need to be its own mini app (fully mobile ready). We may have to scale things back, down, or allow custom configuration options. A full on adilas mini app would be super cool.

- One of our last topics for the day was dealing with costs. We will provide different levels and/or packages that all work and blend together (integrated solutions). If something else if wanted, it will cost and be built out as custom. We love custom and it's part of model. We need to keep that in mind for fracture. With custom, also needs to come cost. Just for fun, Chuck was saying... "I could hand out gold bars on the corner and still get complaints. If they want us to round it out, stamp it, or trim it to make it lighter - we get to keep the gold dust or shavings". We were just being silly but... it's real - custom needs to cost accordingly. That's important. I think that we are getting better at that and really trying to pass on costs and other services to our clients. It has been a learning process. We need our business to make enough money to keep it going. We offer some really great stuff. Our prices need to reflect that.

Great little discussion on fracture (future project - redoing the adilas interfaces and system). I had a bunch of post-it notes with notes on it after the meeting. Chuck really has some good ideas and is forming a vision of what he would like to see the fracture project become. He is great asset. I'm excited to see where it goes!