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.

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.

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!

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.

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

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).

- 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...

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.

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

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

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.

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.

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... :)