On the morning meeting with Steve. As we were going through emails, we had more requests for custom homepages and even some users wanting to go back to the classic invoice homepage vs the newer graphical invoice homepage. We then started talking about all of the different levels of custom...

We went into corp-wide settings, group settings (12 main player groups), page level settings (page control - how does it look and what does it contains and how does it work), and clear down to personal settings.  That got us into a small talk and conversation about an adilas "fracture" account. This is a concept of breaking everything down into mini pieces that could be stringed and/or put together in any combination. This could include pre-sets, pre-built options, special skinning, etc. It could also get into real in-line database extensions, themes, core black box options, etc.

What we are really selling is... We have tons of things pre-built and have a viable solution that has tons of functionality. This is ready and out of the box. We then offer people the chance to build their own application and virtually extend the functionality to what they really want. Basically, Steve was talking on a sales level, and was thinking about having a number of checkboxes... when meeting with a company, you could virtually check the boxes of what we have, we could also allow them to then pick and choose what they want to add on. Basically, we, as adilas, could tweak out our own product and create all kind of custom wire jobs.

We need to apply our own client filters and see who wants to play. We don't want to get over our heads, but we have a great number of guys who can do and handle certain pieces. We have a solution that is usable, right out of the box. We also have a platform that is customizable and moldable (like clay). Steve was also talking about selective selling and really selling our model vs just the system. Not everybody is a fit for what we do and/or offer.

Idea from Steve... Run the system for 6 months and get good at the system. Then come back and tell us what you want to tweak out and/or change.

People want major functionality... however, they also want it to look a certain way (how pretty is it), they also want a level of control (what can they tweak and change).

Function, form, and control - Alan was mentioning the word "Control" - that gets clear down into that fracture type level. We could have preset templates, show/hide settings, toggle on/off settings, permissions and sub permissions, main pieces, sub pieces, and even show/hide of the different modules. Currently, we have everything available... we may actually want to look at module level controls. For example: do you use payroll? do you use stock/units? do you use x or y?

Idea from Alan... What if we did some testing on new users and had them do certain tasks. We then see how intuitive the process are. This would be a refining process and then work from there. As a side note, we have been adding on for years and years. That is our current model. Maybe we need to rework our inter core and make it more module based and then be able to show/hide and/or be able to toggle things (full sections and/or pieces) to an on/off level.

We also talked about packaging and limited packaging of the system... For example: The limited package, the standard package, the deluxe package, and the mother load... package. Not sure what to call things... but it could be really cool. Basically, it all exists, we just show it (smoke and mirrors) in certain ways. Based on the package style and/or level, we could show/hide other pieces and/or features. Another analogy is a race car engine and then we offer the body styles like cars, motorcycles, vans, trucks, semi trucks, or even UFO's (see attached for an older image).

Adilas has a lot to offer... but what if I only need it for this or that? It sometimes feels like taking an army tank out to hunt birds, say something like pheasant hunting or duck hunting. Almost an over kill. What if we could dumb it way down and make it more approachable. Make it into smaller bite size pieces and then let them get deeper if they want. As a side note, like the ice berg analogy, we only show the most basic pieces. Then, if they want more, we allow them to get to it. Maybe either offer certain packages and/or hide everything by default and make them turn it on (at a corp-wide or world level and also at a payee/user level).

Steve - how do people want to buy things? We then need to cater to that level. See the photo gallery for an inverted funnel analogy. Currently, we have people enter with all options (like the top side of the a funnel) and then have them select what they want to get to the smaller level. What if we flipped that model and started out super small and basic... then they could either buy and/or turn of additional modules and/or features as they need them. So, basically, we start super small (like the bottom of the funnel) and work outward (getting bigger like the top of a funnel).

Alan - would like to do a cognitive walk through... What path do they take to do a task? Where did we want them to go and/or do? Where are their eyes on the page and where are they spending the most time? How easy was it for them to follow the path that is wanted? The cognitive walk through would include a small user group, and then the persons being tasked with the tasks would have to explain (verbal and/or written) what and why they are doing what they are doing. Basically, getting into the minds of the users and what they are seeing, focusing on, and/or actually doing.

Wire frames (interactive outlines) and getting to the basic decisions and taking that research back to the coding project. What is the phycology behind the decisions. What are the human levels that we might be missing and/or could really enhance just by display, menus, and structure. In Dustin's words... "putting rails on things".

We also talked about doing different cognitive walk through groups (users not familiar with the system) and how they would do their own different tasks. If they get stuck, why? What were they looking for and what were they expecting? This is more of a cognitive (brain activity) exercise to see what the thought process is and/or could be. One of the challenges for us might be - so many different business verticals and so many different choices... we might need to get a sample and make sure that we aren't hitting just one niche and/or personality type. Lots of different flares and possibilities. We would like to match who would be using the program with what we would be asking them to do. This testing also has some down-sides, such as preconceived notions, using other existing and/or older products, and actually testing people who would be using it.

Alan and I were talking about who we knew and what resources we could tap into to get some basic testing. Just throwing around some ideas. We added in a new community funded project to get in there and do some research and some of the cognitive walk trough's.

After that, Alan and I were reporting on our different projects. We love the options of having black box code, but there are teeth to that as well. We are starting to see the black box section as a huge time sink for the developers if they are making core changes. We have code that is not in master (in the main code repository), it could be changed at any time, and no one knows who has the last cookie. The developers work directly with the clients, and thus, they think that they have the latest code, but a new change could have been cascaded through to the other pages. We definitely need the black box code options and framework, but we need to eliminate as much duplicate code as possible. It is becoming an issue. It is not on fire, but it becoming a thing that needs to be addressed.

Wayne popped in and reported on the database migration project. He is planning on running some new tests tonight. He went backwards and did some major back testing and going back to a test driven design philosophy. He said that he got a great reminder on why we need to stick with a test driven design philosophy (watching out for the little things). The data migration process is super deep... it is basically allowing two different servers to run as they are... then in the background it takes data and tries to re-sync the data to get a perfect match, even though they are different databases with different auto id numbers. That is advanced mixing and blending.

We got into a bigger discussion about standardizing data and using special tables such as flex grid tie-ins and custom dates, numeric, and custom text fields. Some of those tables are great double agents and/or chameleon type tables (they switch as needed). Good stuff and it really seems like Wayne is trying to think beyond the current project.

We are constantly chasing a moving target... part of the fun... :)

Merging in code with Dustin and Steve.

Meeting with Hamilton from Full Circle at 10 am. They are looking for a January 1, launch date. Josh gave us a small update on where he is at. Customer dash board to show coupons, loyalty points, preferences, and maybe even a self check-in (add to queue). A possible manager's dashboard and tracking throughput and what campaigns are used and ratios for closing those campaigns and coupons. Josh is looking to build out some matrix to help show profit, costs, and other demographics (age, distance from store, etc.).

They are looking to add a flag at the corporation level as well as at the customer level on who is playing with Full Circle (who opted in). If both corp and customer levels match up, we can add additional functionality. As part of an advertising campaign, we may just grey out the fields and help prompt the users to sign-up to get the additional functionality.

Josh was talking about a virtual batting average per campaign - how many messages were sent out, what was the ROI and usage, etc. This will be more than just a response matrix, it will include prices, costs, profits, usage, etc. A mix of different stats and variables. Josh is also trying to tie-in things with his new discount rules and discount engine. This is a combo of both existing discounts in the system as well as mixing with outbound campaigns.

There have been some talks on making a standalone version to capture more market share. Basically, a special functional section for adilas users and another one that is just a standalone, that way it may be used in multiple arenas.

Timelines and vision - Josh is going to be breaking things into chunks to help with development and deployment. One of the keys that has been tied in, this past week, was the line item level of or for campaign tracking. That will be a huge key for reports going forward.

Question by Hamilton - what options do I have if I wanted to stand up my own box (server and databases)? He was talking about a go to market strategy. What are the entry points? Options (1, 2, 3, or 4)? Two scenarios, existing adilas users (what do they get) and new users, that don't use adilas (but maybe hit at what they could have)? Basically, Hamilton doesn't necessarily want two code bases but we may have to try to direct them to the main adilas system. Make it a double sale. Hamilton was talking about a mini version of the adilas platform (small and cute and limited) and then over time, allowing his outside users to eventually migrate over to adilas over time.

We talked about a mountain (show everything) vs a ice berg (limited view but more available)... Josh and Hamilton would like to flip the model and expose a smaller portion that looks awesome but has huge potential as they get deeper. It kinda comes down to the entry point (perception). This conversion is basically talking a mini version of the white label concept with a limited entry point. One of the key pieces is the domain name (it has to be pointed to a single server). We also talked about some dual entry points where we have both adilas domains and full circle domains pointed to the same box. Think of it like doors on a building... did they come in from the front, back, side, or up from the floor below? Piece of cake. It comes back to entry points, preferences, and traffic flow.

Hamilton was talking about "dangling" options in front of his clients... virtual up sales of what else if available. If you purchase adilas as a package, it may be harder to up sale the client - they kind of expect the full package. However, if they come in from the Full Circle side, they Full Circle, could sell and/or expose other pieces based on a more modular pick and choose type model. That could be really cool. Once again, showing the full mountain vs just an ice berg with more potential under the surface.

There were some light conversations between Steve and Hamilton about data storage and processing - who is hosting what pieces and where does the traffic come from? In a lot of ways, we don't really care where the clients come in the door as long as they come to play. We also talked briefly about Full Circle being able to expose small pieces as they become available (breaking the adilas mountain into modular pieces that are add-on's and virtual up sales).

As a side conversation, there was some talks about beefing up the reoccurring billing section (reoccurring invoices) and making it more modular and automated. Billing for our services is a big things for us internally. The easier the process becomes, the less time we have to spend chasing it. That leave more time for other tasks. The tuff part is the technical side, the fun part is the selling of the features - from Hamilton. Hamilton wants to use his existing adilas account and setup reoccurring billing from inside the system for his existing Full Circle invoices. We will have Josh and Shari O. help get Hamilton all setup with the reoccurring billing inside of adilas. Josh was stating some ideas about helping to automate things back and forth between the main adilas accounts and the Full Circle billing parts and pieces.

Went into town to work with Industrial Tool & Supply. I brought all of my POS (point of sale) hardware and a projector. I got all setup and then we went for hours both showing them things and trying to get some of the employees up to speed. Most of them were pretty easy going and had a few questions here and there. However, there was one guy who was very outspoken and 50 million questions and what not. That was a little bit crazy.

Anyways, a great meeting. I really think that a few of the people are really getting it and will do a great job. It is amazing how many ideas and great comments you can pick up as you are out and about, in the trenches, per say. Adilas will be better and better the more we all get out there and dig in. If we have to use it, and not just make it, the whole product will become better.

After the sales guys got their training, I spent some time with the accounting ladies and answered a number of their questions. Great session and I'm already seeing some lights come on. One of the biggest things is the ability to edit something... Apparently, in their old system, once you put something in, it sticks and you can't undo it very easy. That seemed to be a reoccurring comment that they kept saying - "I'm so excited that I can edit my stuff. That will be huge.". The other comments were something like - "You mean that I can do that from my own desk and don't have to go use the main sales terminal. That is awesome and will save tons of time." Lots of other fun comments as well.

On the sales side, some of the requests were to make a super simple interface that leads you into the other things. Too many buttons or too overwhelming. They want it super simple. Basically, a help me know the two main tasks that I need and that is it. They also expressed, if I need more options, make a way for me to get to it, but don't put all of it in my face at one time (aka hide it until I need it). As a side note, we had an earlier discussion with Hamilton from Full Circle and we were talking about a super simple entry point and the analogy between a huge mountain and a small ice berg. Even though both could be big and huge, the ice berg (analogy) is easier to chew and approach in a lot of ways (super simple and then more if needed vs getting lost in the size of the huge mountain in front of you). Good stuff.

Another couple requests were: make a simple interface that allowed for users to switch really easy between who was who and who was on what register. Another one was actually putting the word discount as a payment type. I thought that was a good one as well. Lots of good info and ideas.

At some point, we want to circle back around and rebuild a bunch of the pieces and how they act and interact. We would like to call this new rebuild "fracture" or something to that effect. Anyways, here are some brainstorming ideas on the fracture pieces that we would like to sew together. No specific order:

- object oriented approach (objects and data over time)

- use teams and different talent pools

- ice berg vs mountain type analogy (what is being exposed and what are the perceptions - visual exposure)

- settings and different setting levels (corp, group, page, user)

- subs... of sub (everything is fracturing into smaller and smaller pieces) - plan for it and embrace it

- API socket connections and external work flow options

- database scaling (corp-specific databases or corp-specific database tables)

- real in-line database extensions (add/edit/remove database fields and help them flow through the whole system)

- 3D world building - keep going and building out these ideas and concepts - one step at a time

- data assembly line(s) - concepts of tracking phases, grouping, sub locations, allowing flex and checkpoints, permissions, mapping to financials, etc.

- using time or elements of time as a base level and then mix, blend, and share sub functionality and tracking options (more objects and data over time stuff)

- funding and making sure we can fund the planning, design, and development of our game plan

- help files, videos, and SOP (standard operating procedures) - standard and custom

- black box and ways to customize the pages, verbage, logic, and process flow

- summarized data (aggregated data) vs transactional data (all the steps and transactions) - we need both - watchers, feeders, and triggers

- following and dreaming the dream - it may sound way out there... but following that dream is huge

- make a visual plan

- include general testing, unit testing, validation (local and serer-side), and standardizing requirements

- version control and deployment

- going back and doing research and review of older notes - tons of mini gold nuggets to harvest from doing this over the years (make sure and harvest some of our own ideas)

- use of sub homepages and graphical hubs of sort - also use graphics, charts, graphs, and other elements

- summed up data with drill-downs or searches available (basic or advanced) - approach all most everything from a summed up version into a more expansive (expanded) view and/or format

- be able to export any data to CSV, Excel, PDF, and general web format

- smaller mini functions - getters and setters - for miniature database access and updates

- use sub flags, tags, and other similar features - lots of ideas about sub phases, sub groups, sub locations, sub flags, sub tags, sub progress, etc. Lots of prior documentation on elements of time and subs of time, including how to virtually adopt functionality between main player groups (invoices, deposits, expense/receipts, PO's, customers, parts/items, stock/units, vendors, employee/users, quotes, elements of time, balance sheet items, etc.)

- custom look and feel - able to match moving trends

- responsive (able to change size and layout based on device or screen size) - mobile development

- sales - how are we going to market and/or sell our products and services - how are we going to set things up for correct billing and tracking (usage, storage, bandwidth, queries, connections, data, files, images, etc.)

- communications, push/pull notifications, automated things, queues and scheduling tasks, bulk and individual communications

- good project management

- sub permissions - almost down to the function type level (as needed)

- dynamic verbage, custom layout(s), dynamic link builder (favorites), and simple look and feel

If you are looking for other ideas for the fracture account stuff. See this URL or web address: https://data0.adilas.biz/top_secret/developers_notebook_home.cfm?q=fracture

Had a great meeting with Jonathan. He reported on some of his findings. He met with Shannon and got a light tour and then did some additional research. We talked about some of his initial thoughts and feelings. He said that it was kinda overwhelming. Pretty normal. Once he got into it and kinda started to understand that you could virtually move around and look at things from different angles, it started to make more sense. We spent an hour and talked about three main concepts. We talked about the adilas café (new entry point for adilas users), the ice berg analogy (reskinning based on industry-specific needs and wants), and other adilas concepts (photo gallery of ideas). Good conversation and good ideas already starting to flow. I loved it. My goal was to transfer some vision and let him start exploring and playing around.

These are some outside links and pages that we went to for background.

A link to some of our plans for the adilas café - https://data0.adilas.biz/top_secret/developers_notebook_home.cfm?q=adilas%20caf 

I'd like to get Jonathan started on working on the mock-ups for the adilas café and/or the adilas world and/or the adilas marketplace. They are all somewhat tied together. Future home and hub for the adilas community. We want people to come here to work, play, shop, sell their skills and their goods, and participate in different ways.

https://data0.adilas.biz/top_secret/developers_notebook_home.cfm?q=ice%20berg - notes and research on the ice berg analogy of reskinning the adilas engine

https://data0.adilas.biz/adilas_for_business/photo_gallery_full.cfm - small concept photo gallery of core adilas concepts and direction

Meeting with Alan on a number of topics. Just trying to be on the same page. We started out and I reported to him about my demo yesterday and how some of the users really want a super skinny and basic interface. Then, later on, they may want more tools and options. We talked about how that seems to be an issue every time we do a demo. They want the functionality, but they want it super simple and buried and/or configurable to their needs. Interesting, but a common thread. Here are some other topics that we talked about:

- Dealing with navigation - iceberg analogy or maybe icebergs (plural)

- If presets exist, allow the user to reset to blank or to the defaults

- Analogy of drinking from a drinking fountain vs a fire hose

- Create a "simple" shopping cart

- We could add configuration later on

- Devs (developers) often keep adding, design guys are more simple

- We have to and need to play in teams. That is the future.

- Training the team, project management, and building projects as a team - some new challenges. Some of the project management may need to be done prior or separate from the rest of the team project stuff.

- Making sure we have good default or master tables (for copying database tables and structure). That lead into some talks about the developer update table page and how we could use that page to help with the maintenance on the database.

- The last major topic was maintenance. We need to build as if for years, yet still solve the current needs.

Alan and I are going to try to have a weekly meeting where we can just bat ideas around to keep us on the same page. We are thinking about Wednesday mornings.

Jonathan, Steve, and I had a good meeting. We covered a bunch of topics. The notes below are what I pulled out of the conversation. Also, see attached for some new screenshots and concept art.

- Giant group project - Steve, Brandon, and Jonathan all working together - mulitple inputs and ideas.

- Jonathan really wants to create an edit "your page" type interface.

- Lots of icons vs tons of text - simplify.

- Fix some of the snow owl navigation to match the settings. This is true on the drop-down menus and possibly on the all_advanced_searches.cfm page. As a note, the snow owl menus have both on canvas and off canvas drop-down menus.

- When the users are searching for categories and navigation options, maybe think about adding in some flags and tags to help find the nav links and pieces. For example: Say you have a page called advanced invoice search. It may be nice if it has flags such as inventory, POS, sales tracking, etc. Help the users find the related pieces.

- Modals and small in-line pop-ups for settigns and drill-downs.

- Lots of talk about custom homepages, pages that are not part of our normal design process or something custom or specific for a certain user.

- Custom navigation options - simple, preset, build your own, help them find the sweet spot (not too many, not too few navigation tiles/buttons).

- We talked quite a bit about the top bar icons (existing) and how many of the users really like those icons buttons.

- What about things like help files, logout, switch corps, customer queue, shopping cart, chooser, saved favorites, my settings, etc. These are some of the existing top button links and icons.

- We have so many clicks... wearing out the mouse pad or the buttons on the real mouse. Pretty deep and it takes a lot of clicking some times.

- The user specific pallet and being able to condition little mini widgets - charts, aggregated page totals, counts, reports, buttons, froms, etc.

- Blank canvas, setup your own tasks.

- Being able to see preset numbers, values, totals, whatever. We will need to figure out what pieces are wanted and/or needed per section. We can figure that out.

- Expanding and contracting things. This could be settings up sizes for mini windows and mini widgets - getting to just the information that you want.

- Steve wants to be able to scroll both up and down. Basically setting an anchor point or starting point for scrolling. He would like to load things and be able to scroll up or down.

- Lots of asynchronous loading. At a different time, we even talked about a thing called lazy loading (prepping behind the scenes).

- Being able to have sub pages built into a bigger master page. Steve liked this idea.

- Split screen, frames, and sub windows. Being able to remember different sizes and persets.

- Seeing what pages are being used the most. That could really help us know where to focus.

- Problems - load time is slow, too many clicks, want to get to info and may or may not want to go to the actual page. We almost need aggregated totals and being able to push and pull that data to different places. Quick totals or mini widgets - specific to a certain task.

- What if we allowed for a multi split screen?

- Going back to tools that you use - set up your own interface so that you have all of the tools that you need for the job - Example: Say a handyman with a trailer full of tools. He will grab what he needs for the current job.

- Help people get to where they are going - analogy: All the tubes of paint on the right, just drag them out and setup your pallet. Hide the clutter and simplify things. When ready, start painting.

- Everybody is going to be a little bit different, help them succeed. Let them pretend that they they are virtually "shopping" for or from a list of options. What do you want? That could be links, lists of options, functions, pages, or preset or known values or counts. All kinds of ways to get things setup - drag it out, click on it, activate it, choose from a list, use preset settings, and then start using it. Just ideas.

- Custom dashboards, custom widgets with stored settings, lazy loading of pages in the background.

- Some people like it, some people don't, but lots of our navigation is "go anywhere" type navigation... being able to jump as needed is a huge thing for us. We love it.

- People get good in the system. Let them fly once they are at that point.

- Two complaints - look and feel and too many clicks.

- Ice berg(s) - there may be multiple pieces sticking up.

- Keeping the cart icon as a valid nav piece at all times.

- Working on a stacked, layered, and drill-down type learning model. This is somewhat of a presentation gallery of sorts.

- Start gathering these resources and help to organize them. That is my goal.

- Let's look at some of the levels... Thinking of the ice berg type analogy (show a little bit and then expose more as needed)

- Top level -- similar to the adilas café - work, train/play, learn, participate in the community, sell, buy, research

- Flipped over to Word to build an outline. Hopefully see attached...

Emails and other to list stuff.

Talking with Russell over the phone. We had a great conversation.

- Concept for fracture - Being able to remove any of the extra pieces. This goes clear down to the permission level. If they, our customers, only want invoicing and time management. That's all that they see. Even on the permission side of things. They only see what they have turned on. That may require us to stack and group the permissions better. It goes clear down to the ice berg vs the mountain model. We have to be able to remove all of the pieces otherwise the user still sees the mountain even though we are trying to just show an ice berg.

- The other really important thing for fracture is smaller getters and setters. This allows us to add/edit things in a very modular manner. If you want to change something, you can just change it. If you want to add something, you can just do it. This could help out with API sockets, quick calls, and even web components. Back to the old adage, build it once and use it many.

- We lose so much in our transition times - switching between projects. It is very costly both physically and mentally. It is real.

- Working models - if you look really close, we have a number of great working models and proof of concept stuff. There is some real value there. Keep building on that keep working to bring all of those working models and proof of concept pieces more into fruition.

- Empower the users - you can make it happen - we can help you build your dreams. A big part of what we peddle (sell) is potential and hope.

- We spent some time talking about the concept of elements of time. We have build in so many pieces that it becomes a virtual mountain. Russell was talking about a Leatherman (multi tool) vs a simple knife, a simple screwdriver, etc. We really want to help the users. Sometimes they want the big multi tool and sometime they just like the simple knife. We may need both.

- Because of the load, we are able to gain some traction.

- Talking about database pieces and options. There are multiple different models. You have file share databases, server databases, relational databases, document databases (objects and JSON storage), transactional data, aggregated data, object data, etc. You gain if you can mix and blend and get best of the different worlds - connections, storing, searching/filtering, and reporting.

- Helping other people to succeed. That is a huge piece of the puzzle.

- Creating the ecosystem that feeds the people who provide the byproduct services that are needed and wanted.

- Futuristically speaking - There may be some new business needs. This could be adding new departments underneath of adilas or it could be completely new companies (mother/daughter type companies). Thinking of things within the concept of the adilas café - we know that we will eventually need a company for the adilas market, adilas university, core adilas, tons of other options for the other products and services that are needed.

- As we get more into project management, some of our project managers may need some stacking underneath them. For example, Steve may have some projects that he pushed off to some other project manager(s) underneath himself to manage some of those projects. Organizational stacking (who reports to who and how is that organized).

Jonathan from Epic Enterprises came over to my house to meet with us. We started out listening to Steve and Eric over the GoToMeeting session. After a little bit, I started to explain some things to Jonathan. We went on mute but had the meeting with Steve and Eric going on in the background. Every once in awhile we would catch something and it would send us off on a tangent and/or direction change. We were waiting for Steve to join us.

Once Steve joined us, we had a good multi-hour meeting with Jonathan, Steve, and myself. Here are some of my notes.

- We talked about analogies between showing a whole mountain vs just an ice berg (how much do you show and/or reveal - it deals with perceptions of how much there is and how much needs to be learned).

-  We talked briefly about the need for the adilas café and a good starting place for our users to come in and be a part of the community. Some of the people come to work, play, learn, buy or sell their own product and services, and participate in the adilas community. We went over some concepts, graphics, and needs in that area.

- I pitched to Jonathan that we have at least 3 businesses that need to be funded, staffed, and managed. We have the main adilas system, the adilas marketplace (others who are buying and selling their services and products to help support the system), and adilas university (education and training).

- We talked about some progress from one server and being able to share logins (one login allowed access to multiple corporations, based off of permissions and assignments). We also talked about how that model still exists but gets tougher as we keep adding other independent servers. Currently, we can share logins on a per server basis. We can't do a single login and allow that user to access multiple servers. The logins are specific to each server right now. As a side note, not everybody needs to be bridged between servers, but certain users work in tons of different systems and on multiple different servers.

- Jonathan recommended a movie called "The Pentagon Wars" - dealing with scope creep. Basically a project that should have been fairly simple turns into 17 years of development and $14 billion to create it. A comical stab at the mismanagement of government spending and scope creep.

- We as humans, are designed to push too far. We tend to go to extremes.

- Making the system more human like... anthropomorphism

- People tend to be either: stable/reliable (45%), warrior/artisans (27%), idealist/humanist (14%), analytical (10%), other (4%) - all rough figures or ish

- Business is a projection of/from psychology.

- Going from order to chaos, order to chaos, and so forth - cycle that has been repeated over and over again in all ages.

- Suggestion - On the invoice homepage and the graphs... maybe add a projection line on the invoice homepage graphs. Show a forecast and/or projection. This could also be done with an average based on number of days. This came up due to the fact that the existing graphs take month over month data and create a graph. Well, if you have just started a new month... you only have a small number of days worth of data vs a whole month worth of data. Sometimes it makes the graph look like it is trending down sharply when in reality, things are actually doing pretty good. Visual helper.

- Talking with Steve and Jonathan - light intro and talking about their respective backgrounds and interests.

- Jonathan wants to help us improve our company.

- Consultants tend to do one of the following actions:  diagnose, analyze, and/or provide feedback. - Sometimes in that order or 3 step process.

- SaaS (software as a service) is a crazy business model.

- Question (dealing with approach) - How do you sneak up on the elephant? Talks about approaches and why's.

- A consultant informs and convinces. A consultant sees from the outside.

- A few things that Jonathan sees right now, without getting super deep: overdiversification, scope creep, scope seep, lack of structure, possible lack of leadership.

- We don't really like to babysit.

- We are trying to work on our to do list or our tick list.

- People have different skills - putting the people in the right place.

- From Steve, sometimes the environment changes how we act and interact with it - it is not just personalities and traits.

- We haven't spent much on selling and marketing.

- We would like to focus on the adilas café approach.

- From Jonathan, book recommendations - "Good To Great", "Rocket Fuel", and "The Go-Giver"

- Building a company is different than running a company.

- By helping our people better focus, that could help us be more productive.

- Steve would like to involve as many good people as possible - He is ok with not knowing everything.

- Steve wants to keep an independent model and/or have multiple cofounders.

- At some point, you will hit the borders of certain things unless you comply with certain principles.

- So many moving pieces - that makes it tough to both see and figure out the roll out and the plan.

- We may need a plan for who will run the business - we like to create it (dreamers and doers).

- Where does one start? Jonathan wants to start with the minds of the owners.

- We just build things... we don't even stop to try to sell them. We love the building process.

- Steve seems to be the creative type and the organizer type.

- Mixing and blending the persons and personalities - we need all of the players.

- We are trying to create a community.

- Analogy of the bee hive... well, if we have a hive, we may need a queen bee, a tree, and some flowers - we need all of the pieces.

- Steve loves to recruit talent and skills.

- Business philosophy and playing the game.

- Jonathan sees, as far as what we offer: stacked valuable services upon other valuable services.

/////////////////// challenges for Steve and I

1. Use more of Jonathan's time
2. Take a personality test from 16 personalities - Try it in different moods, happy, sad, tired, stressed, etc.
3. Trying to align to business principles
4. Steve and I, discuss some of our known disfunctions - see other notes - search for the key word rejecting

Kelly, Steve, and Wayne were talking about test driven design. There ended up being 7 people on the morning meeting call. The first 45 minutes were mostly Kelly, Wayne, Steve, Cory, and myself. The other guys waited until the end. Here are a few of the topics:

- What is important to the clients in their interfaces? Small disconnect between what is possible, what is available, and how hard/easy is it to use. Also, what if the client doesn't know that a certain function and/or feature is even an option? Education, user interfaces, configuration, training, speed, and tasks at hand.

- Light talked about some of the fracture concepts such as being able to turn everything fully on/off, show/hide interface pieces, mass settings (corp-specific settings and/or industry-specific settings), make sure those on/off toggle switches cascade through the whole system. The iceberg approach vs the mountain approach. Same amount of data, just the approach and perception changes.

- SOP's for adilas developers, adilas reps, adilas consultants, adilas setup people, etc. SOP is short for standard operating procedures. Getting things more standardized and organized. Be able to scale and do it with style.

- On the cart, currently we have some corp-wide settings that help the user determine what they are searching for (items, flex grid tie-ins, recipe/builds, cart favorite buttons, barcodes (mixed sources), and sub barcodes. As we were talking... Steve had the idea of allowing the corporations to check what they search for and in what order to do the search. Currently, they have to chose one of our drop-down cart quick search settings and we then do the search. Steve was thinking that maybe we let them tell us what to search and in what order to do that search. Great idea. Just wanted to record it. Currently, the corp-wide settings is #37, but that may change. Search for it by looking for "mixed sources".

- Along the same lines as above (cart search and scan options)... what if the corporations could set up what they want and then each user could tweak that on a per user basis, if needed. Just another thought. More preferences and helping the system be more effective in the searches.

- Dustin is interested in doing some of the test driven design stuff. He jumped on and was talking to Wayne and Steve about his interest level.

- Two reoccurring themes keep coming up... They are structure and getting more organized. Interesting.

Shannon and I jumped on our normal Tuesday meeting. Right as we started, we got a call from Russell and he wanted to show someone the things he was working on. Basically, a small breakthrough on his current project and just wanted an audience to bounce ideas off of. So, we invited him in to our meeting. As a side note, Shannon, Russell, and I are all brothers and sisters.

Anyways, Russell started showing us some of the new help file options that he is working on. The older system had one help file per page as a whole. Nothing super special and very much a set static page. Some of the new code that Russell is working on is a way to break the help files up into sections and dynamically make them popup and be more consumable. It also offers new options to put in business vertical, industry, or even corporation specific help options. All of the new stuff is there, hidden, but showable on demand without much effort. Light approach on the education mode that Jonathan Wells introduced in some of his prototype demos for the fracture project. Great stuff.

We ended up bouncing all over the place with Shannon, Russell, and I for the meeting. Here are some other notes:

- Help files can seem like a mountain of info... what if we could take those mountains and break them up in to smaller ice bergs of information. Once again, make it more consumable and a nicer presentation.

- Help files could be expanded into courses, videos, quick ticks, settings, and other help or education material. Don't limit yourself to just a plain old help file.

- Russell is prepping and paving the road for where we want to go and who we want to be. Some of that prep work will need others to help fill in the gaps but the virtual roads and ways will already be built. That's fun to think about.

- After Russell was done with his demo on new help files and options for helper sections, we switched and I pitched a few of the concepts that Steve, Sean, and I were talking about earlier today. See this element of time for those notes.

- Switching over to the adilas core platform concept (pretend that you have a floating platform that is supported by the adilas core - different businesses, industry specific options, modules, tools, features, and a virtual city with different buildings and structures resides on the floating platform)... Russell had a number of comments on this subject. He was going so fast that I couldn't catch everything. I should have recorded it. He has some great insight on this topic. Here is what I caught.

- If playing on the platform, what are my boundaries? What are the rules? How do I play? and What will all of this cost? These were questions that Russell wants to know and others who want to play will also want to know. A good starting place.

- Are there maintenance fees? commissions (possibly both ways), license fees, server fees, etc.? Put out and post all the specs that you can - help to sell it as a service. SaaS - software as a services and PaaS - platform as a service type models and mixing the two of them.

- If someone makes their own module, we would love them to be able resale it and/or offer it to others. Once again, what are the rules?

- Imagine being able to quickly choose from modules to build a custom or industry specific tool very easily. That would be awesome.

- What about getting a portion or percent of earnings for using the adilas platform? Just a thought.

- We need to charge based off the components that we offer and what they use. Be able to pass on certain client costs directly to our clients.

- What if there was a certain fee to get in there and play? This could be a service type contract or whatever. Just spitting out ideas right now.

- Back to rules and costs for certain things... servers, domain names, databases, storage, files, images, scans, documents and files, throughput, API socket calls, different modules, components, other pass along charges, 3rd party prices, etc. List it out.

- We could make it profitable by building it, supporting it, selling it, or even pitching it. Lots of options.

- We could also offer other services (virtual marketplace of services). One of which could be consulting for other companies.

- This is a side note, but we have said over and over again, that the services that are needed are more than 10 times the value of the actual product (adilas software). Whoever owns and/or participates in that part of the puzzle will be doing well. Just a small side note.

- If we build it correctly and publicize it correctly, people will come to us and say... Can I do this or that? I want to play.

- It came back to being able to make the application into quick plug and play modules that could interconnect, interact, and turned on/off very easily.

- We talked about pitching ideas... in multiple directions. People pitching us ideas and we, as a company, pitching ideas their way.

- We want really generic tools that may be mixed and blended as needed. Yet, being generic, you could also put a spin or small tweak on it to make it custom in a heartbeat. Quick and dirty changes.

- Help others realize their dreams. Have the ecosystem ready for those dreams to be built and realized. Russell kept saying, people will come to us, once they realize what they can do.

- Speaking about frameworks, conventions, and prepping for growth in different areas. Make it easy, pretty, and powerful. Prep the way...

- Endless possibilities, being able to mix and match to get the perfect flow or perfect mix of tech, ease, and power.

- If we open up our model, we could potentially even buy some of our clients products and pieces if we see merit, need, or wants. Open model.

- Both internal and external modules need to be able to play together.

- We did talk some about IP (intellectual property) and who owns what. It all needs to be spelled out in the rules and how you play the game.

- Think of Legos (kid's (big and small) building blocks - that interconnect) - We may need to make certain things opensource and standard plug-and-play type technology.

- Small talks about limiting and protecting our clients. We may certain limits in order to protect all parties. No limits sounds awesome, but that usually means that someone will abuse things and possibly harm other players. We also talked about ownership and other intellectual property stuff here as well.

- Just some ideas for core pieces that we, as a company, may want to bring up... adilas core, adilas platform, adilas shop (development), adilas services, adilas market, adilas university, etc. "See a need, fill a need" - Robots the animated movie.

As a funny side note... Russell was talking and I was scribbling notes as fast as I could. Front and back of multiple post-it notes. We may want to record the next session, Russell has some great ideas along these lines. Fun.

Great little session on the look and feel and where we are headed. See attached. Also, here is a small copy of the verbage for the summary we did today.

-- from the attached file under a question about the look and feel and user interface.

Summary: When we started Adilas we decided that we wanted to get functionality done first, followed by look and feel. We know it is time to bring that pretty, modern look and feel into play. Some of these aspects are already being approached and more are on the horizon. 

We have chosen to let the clients lead with their ideas, suggestions, priorities, and funding. This has directed our development and our growth thus far. We recognize that many people would like us to just spend the money and make everything pretty, but then you still may not make the goal or hit the mark, which is continually changing. We feel it is important to keep following the client's lead and this will still be our main approach. 

Having said that, we are definitely planning on extending more services, continuing to evolve and refine the interface, and keep following what is working. This will include getting a master plan in place. Many people have heard us talk about this concept called "fracture" - which is a name for a future project which will be a configurable, dynamic interface that will only turn on whatever pieces you want to see. Fracture will include countless ideas, lessons learned thus far, ways to improve efficiency, and breaking things into smaller modules and pieces. This will include more efficient navigation, dashboards, and user friendly features. 

It's beyond the scope of this summary to fully explain here but this will be incredibly powerful to be able to configure Adilas to whatever level of complexity or simplicity you want. This is like an iceberg mountain analogy. You still have the whole mountain but you only expose what you want to see - just the iceberg portion on top. It can make it feel easier, simpler, and more manageable. 

The current model is composed of numerous, smaller prototypes that have been linked and wired together. Our eventual goal with fracture is to make all of those prototypes have the same look, feel, and flavor. This will be selecting the best of class from over the years and standardizing it across the platform/system.

Even though we are talking about look and feel, taking a team approach, helps us move forward in every aspect of furthering the application and model. People who work together are able to achieve more and that is how we are trending and changing our operations even further. More good stuff to come.

If you type the word "fracture" into the developer's notebook you will begin to see how big our plans and dreams are for what we want to accomplish when we build to this "fracture" plan.

Chuck and I were talking about using setup wizards and easy setup steps to virtually walk people through complex or involved processes. We covered a bunch of different topics today. One of them was MVC or model view controllers and how splitting things into different levels allows for more modular code. The thing that changes the most is the view model (display). The other pieces tend to stay fairly similar without huge changes between versions. Chuck would like me to speak with his wife about some of those different levels and some tips and tricks on keeping them separate. She worked with a client that does government work and they were setup with really good deafferentation between data layers, business logic layers, and view or display layers. She is also familiar with a number of different frameworks and possible options there.

As we were talking, Chuck said that one of his goals is going to be working on layouts, use of whitespace, and number of clicks to get something done and finished. Those sounded like good goals to look into and work on for adilas projects. Next, we chatted about navigation, layouts, and the concept of an artist with a pallet and being able to change the layout and control your space (work environment). Sometimes the word space is too deep for people to grasp. They think of stars and constellations. We are currently talking more about personal space and configuring your own environment or working space (homepages, nav options, preferences, dashboards, etc.). Chuck would love to help develop some really cool dashboards and such. That would be awesome.

More talk about wizards and easy bulk setup options. We would love to configure some almost hands-free setup options. Think of what a cost saving this would be. Basically, if we could make the setup easier, we could eliminate some large costs and time savings by letting the users set it up themselves. That is still a long way out, but a great goal. Along those lines, we were talking about how both settings and permissions really need to dictate displays, options, and work spaces. If we did it well enough, we could even offer a free trial or something along those lines. Right now, it takes too much to setup it all up and get someone trained. We can't do it for free because it takes someone who know the system to setup it up, configure it, and get the people trained on it.

If we could get things done in bulk or through simple handholding wizards, that would really help the process. Those handrails or wizards turn mountains into smaller icebergs (perception of what is there to take in or acknowledge). We talked about some possible mini apps or standalone modules for the current adilas platform. Timeclocks, timecards, uers, payroll, expense tracking, point of sale, CRM (customer relationship management), ecommerce, etc. All of the main 12 business functions. Fun little meeting and some good ideas. We would like to include and even start working on the fracture project with some of these ideas. That is and has been a big goal and driving force for what we are doing. What is the next step and how can we get there?

Talking with Steve about limited flex grid, status, and where things are headed. He is excited to expose some of the new tools that we are developing out to the rest of our clients. We are also trying to stay ahead of Chuck and what pages he is redoing and making them look better. That lead us into some discussions on layout and display options such as tabs, accordions, pop-ups, modals, and other modern display and layout styles.

Everything keeps going back to settings. We talked about 4 different level of settings, that we are seeing. They are: 1. Corporation level settings (corp level or world level), 2. Group or player group level settings (12 main players), 3. Page level settings, and 4. User level settings. As a side note, settings are awesome, but they can also make things feel like it is more complicated. You have to play the game of iceberg vs huge mountain. Hide what you can, only show what is needed, but still make it available if needed (like tools in the shed). We see more and more of this type of thing coming as we build out toward fracture and future development.

Another fun thing that we talked about was page views. We happened to be on the time homepage and going over different page views of the same data, but how cool would it be if we could build out reports that show up in calendar view, timeslot view, grouped or aggregated views, or normal details and tabular data type formats. So many options, including charts, graphs, and other layout options. Not to mention, export or save custom report settings. All available, we just need to keep bringing it all together. More stuff for fracture.

The next subject was dealing with getters and setters and how those pieces are so dynamic. Some of our entries have 30-40 fields or choices. We don't want to have to submit all of those pieces, every time, for a simple update. Getters help you get the data in smaller pieces, as needed. Setters help you set or update the data in small bitesize pieces. For example, say you have 30 records of flex grid, each with a possible 40 columns. If you do the math, that one bulk edit page could have over 1,000 fields. What if only 2 pieces of data actually change? Using a simple setter allows you to only alter smaller pieces of the whole without having to carry the whole load. Efficiency!

As we were talking, we can see the value of using small teams to push on projects together. That could really help with resources and giving everybody a buddy to work with. Along those lines, here are some other projects that we may give to Bryan or a small team of developers. Flex attributes for all of the main players (used to be called in-line database extensions), vendor/payee logs (modeled after the customer log section but for vendor/payees), and other projects that already have a small handrail or guide. Anything that has been done before seems to be easier, due to the example or handrail for the developer to follow.

Good meeting - Going over the advanced time search page. Chuck is reworking that page. It is a huge form and has multiple smaller search forms all on one page. He is rearranging them into vertical tabs to show each one separately. That will really help. Here are some of my other notes.

- Chuck would really like to use drop-downs or predictive text drop-down selectors vs open text entry fields.

- Elements of time - very powerful but almost overkill - sooooo much data and sooooo many settings. How can we narrow that down? We talked about a couple of different analogies - cover the walls (imagine all the plumbing and wiring being shown vs a nice looking wall that is pained and has pictures on it), a hood covering the car's engine (style on top and complex and even dangerous below the surface), icebergs vs mountains (how much are you seeing at a time).

- Being able to pull data as needed using things like AJAX (asynchronous data being pulled in just in time, based on user inputs and requests).

- Sort of big and confusing - what does this do? How about that? How can we educate our users without making it look complicated?

- Make the whole thing (elements of time) more consumable - plans for fracture - break it down - Ask our clients and users, how do you use it? Offer preset settings or feature packages - such as: basic calendar, appointments, rentals, bookings, project time tracking, etc. Keep it small and tiny and lead the users along to get it setup correctly and not be intimidated by the number of options.

- Simple interfaces that are to the point and optimized for smart phones, mobile, and responsive layouts.

- Do some market research on how people use it and what they want.

- More dynamics and allow for the users (or preset settings) to change the naming and make it more dynamic. This would be from the top down - what do you call it? What does it do? What is shown, hidden, defaults, etc.? Allow for dynamic naming, layout configuration, and flow of data. At the highest level, almost the data assembly line type concept. If the preset options don't do enough, allow for a build your own layout system (super configurable).

- I mentioned to Chuck that we had some other plans for time templates and dynamic settings that we want to build into the next level (fracture project). See elements of time # 8004 for more details.

- Timing and budgets - sadly, it may take months and years to get all of this done. We have lots of changes that we would like to do. All in good time. Keep floating, watching timelines, budgets, and available funding. We'll get there.

- For fracture, we talked about some sort of education mode. This could be small popup walk through guides, wizards, tutorial helps, or whatever. Along with this, if we show little popup helpers, keep track of what has been viewed and what had not yet been reviewed. Be able to reset if needed.

- Chuck and I also talked about date pickers and time pickers. We looked at a few samples. Ideally, with the new UI/UX changes, we will be able to add both date pickers and time pickers to all pages that need that type of user input fields or selectors.

- The value of a team. We don't have anybody who can do everything to the fullest level. Plus, that would take way too long. That's where the team comes in. We've got backend guys, frontend guys, designers, database guys, coders/developers, project managers, dreamers, admin, and managers. Good stuff! Keep going in that direction.

Long meeting between Steve, Cory, and I. Cory was reporting on tons of different projects and getting our input and suggestions. We covered tons of different topics. Here are some of my notes (from 10 pages of post-it notes - didn't know it/we would cover so much). The original meeting was only setup for an hour. It went a wee bit over... :)

- Talking about tons of custom label options. More talks about what to do with Calvin's custom label builder. We've spent a lot of money there and want to really get a return on that investment.

- We talked about bringing projects more internally with our guys and breaking things into smaller and smaller pieces.

- On labels, we had a request to be able to do serialized labels (up or modify counts and counters based on batches or packages).

- Using tons of our existing tools and refining those pieces. We have a ton of tools in the shed (virtually).

- Lots and lots of talks about breaking up the bigger projects into multiple smaller pieces. Along with that, we need to be able to charge money for bigger estimates. Everything takes time and effort. Either that or be able to recoup the amount within the bid or estimate.

- If we are doing real custom work, we need to charge for that. Often, we end up taking a hit.

- The trend seems to be (globally) transactions and details going into aggregates and summaries. We have had so many 3rd party analytical companies wanting to use our API sockets to harvest and use our great data sets. We would like to do a bunch of that analytical work inhouse vs farming it out to a 3rd party. All of these 3rd parties are just working for individual companies, but you can see the trend happening. Our clients are really wanting to get to the business intelligence level (BI) for viewing their data, snapshots, counts, summaries, and other aggregated data or stats.

- We went over some pros and cons of using the adilas API sockets. Back and forth on monetizing those channels and also making sure that they don't get abused or flooded.

- Lots of talks about the item catalog and the image catalog. As we use more and more API sockets, we could really use bigger and bigger bulk tools to help with data standardization and speed of deployment. Lots of positives. We, as a company, could also sell more systems if we brought in the enterprise level (way up - cascading info down to lower systems). Good stuff.

- More bulk standard tools. This just adds to the votes for building out the value add-on core model with different levels. Just as a recap - the value add-on core model deals with 5 known levels. They are: 1. Transaction core (current adilas system), 2. Industry specific skin, tools, and features. 3. Any custom code on top of the main system. 4. BI - Business Intelligence levels (stats, sums, counts, averages, mins, maxes, aggregates), and 5. Enterprise levels - connecting multiple worlds in a hierarchical type system (roll ups, roll downs, transaction corps/worlds, aggregates and sum corps/worlds - also dealing with permissions and access). We really want this type of a system for our future fracture project. We already have a number of pieces to this project (all kinds of prototypes spread all around the system), it just isn't all put together. That would be so awesome, clean, powerful, and hopefully pretty!

- We spent some time talking about our clients. Sometimes they get pretty creative. That is both good and bad. If they get creative, and find errors or break things, we just fix them and keep going. Other times, they totally use certain tools in ways we never would have imagined and/or foreseen. That can get interesting.

- There have been some requests for bulk tools for updating sub attributes and bulk sub inventory tools.

- Cory kept asking - Who are we? We tend to build generally but then we have all of these industry specific demands that keep coming at us. It makes it really hard to know where to focus. We really need to decide who we are and then hopefully that or those choices will help guide us.

- Dealing with Metrc (state compliance systems), we've had the request to build out more individual user type functions. This is dealing with more employee/user type permissions and settings. Currently, most of our Metrc transactions are done on a corporation or world level. The new requests are to do the exact same things but break it down on a per person basis. That sounds awesome, but that could be hundreds of thousands of dollars in development. We would have to create the one-to-many relationship, make sure that they were valid, then sync up users and permissions between systems in order to play. Then, to further make it kinda crazy, you would have to check user permissions (remotely) then attempt the connection, then if it failed, figure out if there was a global (higher up) option that you could do so that it wouldn't break all of our code and processes. It could be a huge project. Lots of unknowns. As part of this project, we would also have to add more history tables, who did what, who changed what, who has permission to do what, and making sure that each individual keeps their keys and tokens updated. It sounds like a small nightmare.

- We seem to build in general and then use it specifically as needed. Custom code on top of our own standard package, tool, or feature.

- Going over the cost of building and building. One you have to build it, then you have to maintain it, and upgrade and support it. The costs keep increasing. This topic lead us back to questions about who are we and where should we be focusing?

- There is a growing need to use asynchronous type loading like AJAX or some way of breaking huge datasets into smaller pieces. It is totally common for us to need to show or export 10,000+ or even 100,000+ records at a time. The current process tries to take that whole thing as a single bite or single attempt. It's just too large and slows things down.

- Some time was spent talking about loyalty points and keeping track of the total liability. More talk about other reports that show sums, grouped values, look-back capable reports, and using ACV (actual cash value) for recording loyalty points. We do a bunch of that, just refining the process and making it even smoother.

- Need for messaging or using the message marketing features that we have already built. There is a growing need for push notification and two-way communications outside of the main app or website. The client portal is growing in needs and options. More mobile ready or full mobile pieces are going to be coming down the pipeline. Everything seems to be trending in that direction.

- Question - do we fill in the gaps on functionality or try to update the look and feel? It sure would be awesome if we could virtually turn things on/off based on the UI (user interface) and settings. We would love to set things up super simply and then let the users add on or take away from our smaller base level. A new mini version of the shopping cart is in great need of these fracture type level settings. Start small and simple and then let the users build on or configure things as needed. Hide anything that we can unless asked for. Then when it is done (using the tool or feature), it can be hidden again. Every page needs show/hide options on a per page or per section level. Totally customized.

- Along with the show/hide options talked about above, it would be so cool to show all of the options and then say - what do you want? You tell us. More fracture stuff (where we are headed). Mountains and iceberg analogy stuff (it still needs to be there, but what is shown and/or exposed).

- We talked about extra costs and prices for some of the other add-on tools and functions. Some of our stuff (tools and features) takes a major amount of work and effort. We would love to sell more training, consulting, automation, and other professional services.

- News and updates and the importance of keeping our users up to date and informed. This seems to be a constant need and keeps evolving. Content and making and creating new content (creation and maintenance).

- Lots of talks about prioritizing efforts for different persons (parties). Diving out responsibilities and sharing info across departments and across people (users).

- Using videos - the value of education and training. Selling our other services. Scheduling and setting up ongoing training efforts. We would love to make lots of polished smaller videos. Laying it all out for our clients (on demand education or just in time education). We could really use our website to toot our stuff for different business verticals. For example: Revamping our manufacturing site and pages. We can handle... (fill in the blank) for manufacturing or whatever. That is a deep pool (manufacturing and production type businesses). The trend seems to be leading us more in that direction.

I joined late. Steve was already on and Sean had already been on and left. When I got on, Steve and I were chatting about the Bear 100 mile race and some thoughts and ideas. Steve had the idea to put some kind of stats or leader board dashboard on the public runner portal pages. A quick 10,000' overview. For example: (pretend that the letters are numbers and that it looks cool) x signed up, y did not start, z started. We then could show where everybody is at... x at this aid station, y at this aid station, this many finishers, etc. Basically, a quick dashboard type overview and add some eye candy (stats and counts). Show the tip of the iceberg and then let them drill down as they get the data.

This led us into a conversation about transitioning into graphical homepages with quick snapshots, quick numbers, counts, maxes, mins, averages, and other quick aggregate values. We would love to add this in for our fracture project or fracture concepts. Do this on every page. Alan did some small graphs on the main invoice homepage. We want this spread throughout the entire site. All of the key player groups - (customers, invoices, quotes, items, stock/units, elements of time, balance sheet items, deposits, expenses, PO's, vendors, users, etc.).

Met with Aspen to look over her world building presentation. We ended up getting into this little Q and A session and small virtual interview. It was kind of fun. Aspen took a bunch of notes on a Google doc. I won't share all of the info that we covered but I may pull out a few key pieces.

- Settings and speaking the client's language is a huge part of it - where it starts or where they (the client) gets some buy-in. Once you speak their language, they feel more comfortable.

- System configuration - I like this, I don't like that, can I hide this, can I make this show up here or there, etc.

- Using world building concepts in trainings and demos. Once the clients figure it out and catch the vision, they use world building terminology in describing what they are wanting or what they are hoping to achieve. Basically, if you can get the client to start thinking about the bigger picture, it really gets the juices flowing and the ideas rolling in. Virtually get the wheels spinning.

- Keep building what we know and then deal with other ideas and requests as they come. Custom code vs settings and toggle on/off features. A growing blossoming idea farm.

- We have outgrown a number of different models. For example: We started out with 5 different roles for permissions. Things like sales, mangers, accounting, admin, and backend/web. Now we have over 170 individual permissions that may be applied in any configuration vs the five simple roles that we started with. Also, our first round of corp-wide settings was to build out six corp-wide settings. We had to flip the model when we got up to the 400 ish level. We ran out of room. We ended up building vertically (variable/value pairs) and using custom setting objects (JSON objects and linking similar settings). Tons of ways that things have exploded, changed, and evolved over time. It's been a process. The other big challenge is adding in or taking away new stuff without affecting those who are already in there working (existing clients). You almost have to make the system a chameleon that can change its shape and color on the fly.

- Aspen and I talked about the potential of doing a white label approach. Kind of like the Intel chip inside of a computer. It could be branded however, but the chip is what the whole thing rides on. For example: You could have an HP, Dell, or some other brand of laptop but all of them use the Intel chip as the underlying microchip processor. We would like to do something similar. Whatever brand, powered by adilas.biz on the inside. We don't have to be the main company like HP or Dell or whatever. We could easily just help power those brands using our tech and underlying engine.

- Along the lines of a white label - It would take a potential competitor years and years and millions and millions of dollars to do what we can do right now. If they saw the value of a white label option, they would be smart to go in that direction (saving time and money). Just reskin it and start selling it vs building it from the ground up. There is already a market for what we do (based on our current clients and 20 years in the business and millions and millions in revenue - even though we aren't done yet).

- Aspen asked me about a couple of features that we are using right now and how they relate to world building. I mentioned elements of time and the flex grid tie-ins. Both are hugely customizable and fill gaps and needs, out the door. We talked about selling in bulk but tracking individual items, tracking processes of change (dealing with sub locations, sub phases, or steps of a process). One-to-many relationships, custom fields, preset settings, configuration, and being able to limit what is shown (even though behind the scenes it could be very complex). Tons of samples, examples, prototypes, and working models. We have nuts and bolts companies, bike shuttles, ski schools, and tons of other companies that use these pieces. This is just two pieces of the much bigger puzzle.

- Most of our progress is somewhat limited by outside funding, not ideas or needs. We have huge dreams; it just depends on where the funding for that comes from. This whole thing has been build on a garage type budget. We have ideas and projects that sometimes sit for weeks, months, and years before we can get to them. Our list for an MVP (minimal viable product) keeps revolving and growing. If there is funding, it moves to the top of the list. If not, we chip away at it little by little.

- Lots of analogies between our system (the adilas.biz system) and the body. Often, we start out talking about things like arms, legs, feet, etc. As we get deeper, we get into layers, joints, muscles, system, and clear down to the cellular or molecular levels. People keep wanting to be able to control and/or see the next layer, the next layer, etc. We haven't found the end or bottom yet.

- Aspen was asking what is the difference between world building and fracture? I tried to explain that the fracture project is more of list of lessons learned, ways to speed things up, ways of standardizing things, allowing for customized things, show/hide things, toggle on/off certain settings, full control over flow and display, and controlling things at a smaller detailed level. World building is what we are trying to do and/or accomplish (think bigger picture). We use fracture (aka the next generation of the system or application platform) to get to the bigger world building pieces. We talked about Legos and building blocks of different size, shape, and functionality. Sometimes you need to play in bulk (bigger or preset pieces), medium pieces, and super small pieces.

- We got into talking about the iceberg analogy (or ice berg analogy - different spelling) and how if we could have the whole mountain but only show the iceberg, it would sell better than something seeing the whole big mountain. It makes it look too intimidating (showing the whole mountain). The iceberg looks so much more approachable (be able to configure just what you want to see and use). That's where fracture and some of those ideas come in. You could still have the whole mountain (under the surface) but only have to show what is needed or wanted. Put the rest of the engine under the covers (under water) like the Intel chip inside of a computer. It's all perception and expectations.

- Ideas that don't get exposed (out to the public) can sometimes die in a hole. We talked about if a bigger company was pushing some of the world building concepts or data assembly line concepts, they would sell like hotcakes.

- Towards the end of the meeting, we were getting into costs, growth, and projections - numbers, costs, financials, etc. Fun stuff!

Anyways, a great meeting. Aspen has more notes in her Google doc where she was recording things from the small interview. I enjoyed the chat and the learning session. Sometimes you don't know what you have until you start trying to verbalize it. Good stuff!

Meeting with both Alan and Aspen. I took some notes and Aspen took some notes. After the meeting, I did some more note recording and note digitizing for 6/15/23 and for 6/16/23.

Alan was on with us for the first hour. Here are some of my notes. See attached for all of them.

- Let's build out the MVP for the plan - general fracture or adilas lite planning session - what documents does that mean and/or require?

- Two of the first main things we want to do is define the jelly fish model (business structure) and the value add-on core model. Those two are some known needs of where we are heading.

- We spent quite a bit of time talking about how to break functionality and features up. We want to keep those separate as far as options.

- I showed Alan the presentation gallery and the outline of the business functions. There is quite a bit of work that has already been done there. Great resources.

- Small packages and/or starting points - We could call it whatever - recipes, packages, templates, industry specific skins, presets, etc.

- Alan wanted us to think about tiers and scaling - both vertical and horizontal. I was thinking, what about the Z scale or the depth/layering axis. Just for fun 3D scaling and 3D world building. It might be fun to explore this.

- We talked a little bit about pricing and tier levels. We would like to set breakpoints, ranges, and fees for going over.

- We asked Alan about his vision for adilas lite and fracture - He is really excited about creating a solution that is light weight and very efficient. In his words, he said, How can I get the most power with the least amount of drag? We went on to talk about hiding things that they don't need and getting them to the meat of the operation as quickly as possible. We will do future planning sessions where we look at each section and slim it down to the minimum or minimal requirements.

- This is a side note, but as I have been thinking about minimal pieces, I keep coming back to a concept that we were looking into called standalone declarations (full entries without any other connections and/or supporting documentation). They exist by themselves but they also may be mapped and pointed to the right place. We could sum them up, count them, map them, and keep it super simple. Originally it was going to be something that could be made for financial documents (P&L and the balance sheet)  but technically we could use them in any way. Simple standalone pieces.

- Spend the time and do some market research on what business verticals we could hit and take care of.

- Lots of talk about automation and even automating the setup of new systems. Let people try things out as a free or limited version. We would setup thresholds, limits, ranges, or whatever. We want people to try it out and like it.

- We talked about ice bergs and mountains (perception of how big it is). We also switched and talked about the depth of the water... pretend levels of swimming - Imagine that you are at the beach - you could get your feet wet, do some wading, swimming, snorkeling, or scuba diving. All at the same place, just how deep and serious are you or what are you looking for?

- Once we have a list of things that need to be done and/or worked on, we get to prioritize that list. What do we want to build out and when?

- Alan had the idea of putting our outline information into a database. That way we could just query things (just in time) as needed. That way we could make the lists super small and then allow for it to be expanded at will. Great idea. Simple displays with drill-downs. Almost the presentation gallery for sales, marketing, pricing, features, and education.

- We also want to highlight future plans and what is up and coming. We change things all the time. Make that part of the plan and the part of the presentation. Put it in a database and let our users pull back what information they want and/or need. Self-building templates, feature lists, tiers, and other levels.

Printing out some elements of time as a back-up paper copy. Prep for a group meeting. Once the meeting started, we did some small intros. There were 10 of us on the meeting. We went over concepts of throwing stuff at the wall, seeing what sticks, organizing things, Alan gave a small PowerPoint presentation (see attached). We talked about exposing the peaks, mountains and ice berg (peaks) analogy, tiered versions, pricing matrix, features & who has access, prototyping with code models, frameworks, libraries, the jelly fish model, a new mini jelly fish model, and tons of other topics.

We got into topics of growth, retention, code development, IT/Servers, and Cafe/Marketplace options. Great discussion on R&D and how R&D plays on both the maintenance side (stabilizing and making the current product better) and the growth side (new stuff and pioneering).

Spent some time talking about the SWOT analysis, lessons learned, and mission statements. This is an idea from Hamid, on the mission statement - Mission: Adilas - Build Your Solutions. We got into some user stories, scenarios, and recruiting help from the guys/gals. We talked about who wants to help and what they could do. Overall, a good meeting. We recorded it, at least the first part (first 23 minutes). It stopped recording when we switched screens and switched presenters. Anyways, see attached for some other notes, the PowerPoint slides, and the link to the video recording.

Good group meeting with a progress report on the ship B, adilas lite stuff, and fracture.