- Light overview of our vision - overarching adilas design vs individual business vertical designs and mini white label options.

- Talking about the reports homepage... where can we go from there? Currently, there are reports for invoices, sales by, items, parent/child items, vendor stuff, and customer based reports. Jonathan was wondering about all of the other reports. In a way, all that adilas is a giant reporting application. Data comes in, then our users want to pull that data back in some way. That would be super awesome.

- Going to some graphics and screenshots - Comparing old and new report settings and pages. One was on an older code set, new code sets, and even permissions and settings. Jonathan was noticing small differences based off of those vars (old, new, permissions, and settings). Lots of moving pieces.

- What to expect... We talked about how the adilas core graphic was divided into main system players, then sub homepage based on that player group, each player group also had searches, reports, and other data or group specific output. Each section (main player group) will also have tons and tons of data associated with them.

- The interactive map has a button for history and reports up in the top right hand corner. That is a pivotal piece (corner piece).

- What do we do? We store data, we show data, etc.

- Jonathan was listing out pages and then sorting them based on names, pages, sections, etc.

- So much redundancy (in the design and in the navigation) ... new users can get lost. Does this button mean the same thing that I already saw or is this a different section? Because there are so many ways around the horn... it somewhat makes it hard to find your way around.

- The shed and tool box analogy - You will need a lot of different tools. Most of them you keep in the shed and/or toolbox. However, each time you do a task, you want certain tools for the task at hand. How can we help them get to the tools that they need and still keep it super simple. A similar analogy is an artist and a pallet of paints. They need them all but they only are usually dealing with certain ones per painting.

- The deeper we get, the more we get the comments... How can I go faster? How can I do more? How can I see more? How can I mix this and that? How can I (fill in the blank)?

- Jonathan asked... Do you think people use your system more for viewing data or for entering data? We answered, both. It totally depends on which side of the fence you are on. Are you a salesperson at the counter do a sale or are you a manager looking at financial? It all depends.

- We lightly talked about custom links, custom buttons, and custom icon navigation.

- Some of the upper management users are wanting things quicker, faster, easier - things are going to mobile apps, quick reports, dashboards, etc.

- Screenshots of searches on the sides, data is in the middle, and add new is at the top. Simple layout and then keep it standard on all group level areas (customer, deposits, invoices, PO's, expense/receipts, parts/items, stock/units, vendors, users, etc.) See the screen shots.

- Being able to use settings (using the gear icon) to get rid of certain columns, sort values, pre-set setttings, page level settings, users settings, group settings, show/hide columns, custom naming conventions, etc. Super cool fracture type ideas and tech. This would be awesome for the upcoming fracture type system.

- Standard of here is how you enter data, here is how you view your data, here is how you get to certain areas quickly.

- A lot of the system is built out in tons of standalone URL or pages. That allows us to jump and interact with whatever page/tool that we want. As a technical side note, some of the pages do have required flow and pages but some of that is negotiable and/or programable.

- Jumping back to the mind map type overview. We also talked about the interactive map and how we could use it to drill-down into more details from there. Being able to flip flop the view. Allowing for multiple different views of the same things (what is your style).

- Being able to flip into an education mode and then be able to show simple videos, walk around tours, and step-by-step directions. This could show/hide extra verbiage, show/hide quick images, show/hide quick video tours, etc. Education is a huge key.

- We are seeing that every page is going to need an id number for saving settings on a per page level. This is feature already exists. We just need some data entry to get all of the id numbers. Jonathan would even love to store possible CSS settings and such on a per page level. Lots of roads leading in this direction, page level controls and settings.

- See attached for image uploads of concept art, icon boxes, magic 4 square, search and results options, mind maps, etc.

Both Russell and Jonathan were on the meeting. We had a good talk and discussion and it was mostly lead by Russell. In a way, we lightly took over the meeting and Jonathan didn't really get to report on much of what he was working on. Here are some notes from the meeting.

- Talking about a visual appeal

- Function vs form (look and style) - this is always a debate

- We need to find the balance between the number of settings and what can be customized

- Russell really wants things to be... powerful, beautiful, and easy

- We spent some time talking about design concepts and layout options

- Small animations and even icon animations

- Both dark and light themes (general overtones)

- We talked about setting a choice way up high at the top level and altering other sub colors and settings based on the top level choices

- Education mode as a highlight - we may want to focus on this and figure out a way to capitalize on things. From our feedback, this seemed to be a highlight and an interest point.

- Help files and having the little side menu be dynamic and let the users decide to show/hide the help options

- We talked quite a bit about videos

- Jonathan was talking about having the help file side-by-side with the page that it is referencing. Being able to see the real page and the help file (tutorial or image) next to each other.

- Dealing with help files, we talked about all kinds of different types of media, visual, print, courses, etc.

- One of the main goal is... helping people to navigate the system. Some of that means hiding certain things, streamlining the flow and processes, and being able to get our users to navigate through the system.

- The onboarding process - that is a big key

- Russell and Jonathan were talking about user tests and user testing (what can they do by themselves and what do they need help with?).

- Lots of talk about removing the clutter

- Using the quick search and being able to search the systems for key words and then flagging and tagging the other navigation options for key word searching.

- MVP - Minimal Viable Product approach - keep it simple

- Jonathan really wants to get a requirements document setup. That would really help.

- Part of the conversation was dealing with getting both Jonathan and Russell together to get and share ideas

- There are two parts of the system that Russell really wants to help out with. They are the shopping cart and the media/content pieces.

- Light talks about making a single page interface for the cart and other pages and/or processes

- Preferences vs opinions - we are really trying to help educate and help out our clients. It is really hard to please everybody.

- Spending time to develop and explain the "why". That is how we help motivate and influence change.

See attached for a few screenshots from Russell.

Shannon and I were talking about new happenings inside the system. From Shannon, setting up healthy boundaries - that really helps. Setting up boundaries allows for showing respect for self and for your clients. It is important.

- Dealing with boundaries, we need to setup clear expectations of we go to here, this is provided, this is not, and anything beyond this point (needs to be defined) we need to charge for. It all comes down to expectations and what not. This is where we begin. This is where we end. These are your responsibilities.

- The system really is "as is" - anything beyond that needs to be paid for and covered.

- In a way, some of our clients virtually bully us and just push on us so hard. If we set some healthy boundaries, that really helps.

- Shannon and I went in and looked at a video from Jonathan Wells - video demo of a new adilas nav and layout - As we were watching, we kept stopping things and talking about it. If the link above doesn't work, try this one.

- As we make the things more standard, that will help with navigation, lower the need for training, and general ease of use.

- Putting the settings right where they are used and/or needed.

- We loved the idea that Jonathan had about being able to quick search nav (navigation options, buttons, and links). This allows a user to virtually type in a word like discount and the application would show all kinds of links, options, pages, etc. Super cool idea.

- Education mode within adilas. A switch that could be turned on/off at any time. That would really be awesome.

- Tag line from Jonathan - Where Operations and Accounting Meet

- Being your own style and be willing to go through different drafts and iterations and versions. We get to say and be our own style.

Met with Jonathan and went over our own version of a spec list. What is needed? We talked about his latest video walk through and the impact that it is having on different key adilas players. Good stuff and fun to see the reactions. Lots of positive feedback. Here is a link to the video from a couple of days ago - https://adobe.ly/2PEhYI4

Below are some new notes from our meeting today.

- The value of the page and what is really important? Focusing on the task at hand. Sometimes we can get distracted by the tiny details.

- Spec sheets - what does that mean and what are we really looking for? Sometimes that spec sheet develops over time through meetings, feedback, and decisions. Currently, we are somewhat in the mode of just in time spec sheets vs big long lists that have been prepped and formatted. We may lose some efficiencies but we gain in a real way by talking about real ideas and subjects. Not everybody likes it this way.

- Timing and what is needed and when. Timing is huge.

- Talking about adding colors and backgrounds. See attached for a few screen samples with some background colors and background images. Just playing around.

- Meet, change, meet, change - R&D format (research and development) - This is somewhat how we are managing the projects right now.

- Delightful (key word) - We want it to look good and be fun to work with (delightful).

- Global nav searches and pushing that further (new quick search option). This could be huge. Being able to search the app for anything that matches a few specific key words. We could show navigation, buttons, links, help files, videos, tutorials, tours, tips, etc. Fun options to think about.

- We spent a little bit of time talking about what the "education mode" means and what and how that would look like. We decided that if we turned it on, it would show all kinds of helpful info and tips to help orient a user. If they want, they could turn it off and the tips and hits would go away. They could turn it on/off as often as needed (the help options would change based on where they were in the app).

- Making custom software easy - that's what we are trying to do.

- Sent Jonathan a link to some research on fracture - https://data0.adilas.biz/top_secret/developers_notebook_home.cfm?q=fracture&sort=asc - as a note, fracture is somewhat of our code name for some of the ideas of where we want to go (future project). Things keep breaking and sub dividing (fracturing) right underneath us. We are trying to embrace the changes and roll with the changing landscape.

- Going forward, we are planning more screenshots with more customizable options, real data layouts (fake data but simulating real pages), being able to drag and drop to help with sorting, and building up to CSS style guide stuff. As we go further, we may end up adding graphs, charts, and other eye candy type stuff. Just trying to fill out the navigational app with mock-up data.

Meeting with Jonathan to go over some progress. We haven't met in a few weeks due to holidays and what not. The meeting went well. Jonathan and I were on the whole meeting. Steve joined us in the middle for a part of it. Here are a few of the things that we did and covered:

- Review of the education mode - see the screenshots. The education mode allows a user to turn on/off additional helps, tips, help files, verbiage, videos, graphics, etc. The user can turn things on/off to keep the interface more clean and streamlined. If they need more help, it is available at the touch of a button. Side note, added this link to a small video on the education mode on 8/14/23.

- Review of the invoice interface with some fake data. Jonathan is working on showing mock-up data and how it may look and flow, as the user interacts with the system.

- Talking about style guides and standards - design systems - This is how we will end up standardizing the look and feel over multiple pages, components, reports, and features.

- Components and using consistent assets (visual and code resources). Both in the design and in the code - design/code once, use many.

- Talking about mobile development and more needs for mobile ready pages.

- We also talked about the placement of certain eye candy pieces such as graphs, charts, and other stats. Leaning towards the reports pages and/or section.

- We briefly talked about Jonathan's research on fracture and breaking up the system into smaller pieces. Being able to have the mountain of tools and options (features and benefits - current adilas system) but only showing what is needed (turned on/off and properly configured) and streamlined per industry and per company within that industry (making custom software easy). Basically, the ice-burg model. As we got into this, we ended up talking about the core product (the main adilas platform) and how we could allow for industry specific interfaces and settings to play over the top of the skeletal type model.

- The skeletal type model deals with the underlying systems... imagine a person with just a skeleton structure. You could then put normal clothes on that skeleton structure. Pretend this is core adilas (plain jane vanilla). Then you could dress that person with industry specific clothing to get all types of different outputs. Every industry has a different look and feel, verbiage, style, flow, etc. That is like putting on specific clothing on the skeletal system.

- Towards the end, Jonathan and I were talking about the shopping cart and how that part of the system really needs some loving. So many pieces converge on the shopping cart and point of sale interface (POS). It is pretty awesome. Here is a small help file on the shopping cart - click here. We talked about some of the known pieces that converge inside of the cart such as smart cart logic, customer loyalty points, tiered pricing structures, discounts and discount engine stuff, inventory tracking, sub inventory, mini conversions, labeling, coupons, payment solutions, sales and promotions, etc. Once it hits the cart, it gets put into the database and starts its life cycle. We talked about how the shopping cart and things that flow into it and out of it are kinda like the heart of the application.

Meeting with an outside developer who is setting up a custom VPS with some data for a company to run his own analytics. This developer was hired by the company to run some other reports and such through his own environment. Our job is to supply the VPS with a copy of the live data so that the developer has a working model and environment that he can play with. Awesome idea and concept.

Anyways, we went over some database stuff, mappings, key fields, data relationships, and how things tie in together. We did some drawings and other tech talk stuff. As a fun side note, it would be really cool if we have some of this same stuff (what makes it tick) really documented out so that other developers (ours and outside developers) could tap in and play. That would be super cool. Future project. As an idea, maybe a tech mode (similar to the education mode or data mode or permission mode) for the fracture stuff. In tech mode, we could get into the nitty gritty details of how things flow, connections, data relationships, decision trees, conditions and conditional logic, switches, validation, keys, etc. Super techy stuff. The tech mode would talk to the developers, programmers, and/or the curious persons who want to see the backend logic and design.

Recording notes and adding documentation to the different entries and elements of time. Lots of fun screenshots in the past couple of days. Here are some fun entries:

https://data0.adilas.biz/top_secret/time_web_gallery.cfm?corp=22&id=1532 - WanderWays - camp adilas project

https://data0.adilas.biz/top_secret/time_web_gallery.cfm?corp=748&id=5530 - WanderWays website prototype project

https://data0.adilas.biz/top_secret/time_web_gallery.cfm?corp=748&id=5864 - internal adilas mock-ups - fracture project

We invited a couple of the guys to meet with Jonathan today. The main topic was the shopping cart or internal cart. So many things go on inside of the cart. It really is a heart or very viable piece of the equation. On the meeting today we had Chuck, Alan, Steve, Jonathan, and myself. Chuck started out by showing a few shopping carts and point of sale (POS) options from his WanderWays - camp adilas project.

Jonathan then showed us around some of the things that he is prototyping, including the custom navigation options, settings, and custom configuration pieces. We also went over things like the education mode, simplified searches (hide search form fields until needed and/or wanted), and combined searches. Lots of stacking, tabs, and just in time access menus.

After that, I did a small demo on how the cart works and how things get configured and used inside of the internal shopping cart. We switched carts, we did discounts, assigned customers, restored quotes to cart, added notes, payments, and all kinds of options. See attached for a small video recording of the walk through.

The last part of the meeting was dealing with some critiques and ideas from the different guys on the meeting. Good stuff and making progress.

Updated - as of 2/3/20, two new video links were added (see attached) for concepts of the invoice mode (mock-up for fake data) and also a proposal for the education mode and how adilas fracture interface could inter connect with the adilas café project. See the attached videos for some overviews.

Two hour meeting with Russell, Steve, and I. Good stuff and we covered a lot of ground. Here are some of my notes:

- We would like to create some CSS snippets and examples. Make it easier for the developers to use good looking code.

- Updating and backing up our WordPress stuff. This is constant maintenance stuff to do.

- We really want to fully use the snow owl theme and the bootstrap themes that we have started to. They look really good.

- Focus on the user experience and keep refining the processes that we already have.

- Helping the customers sell our product by word of mouth. Russell wants to delight our users.

- Russell spent a lot of time pitching the vision to Steve and I. We were buying it... fun meeting.

- Russell wants to do a campaign (focused coding sprint) on revamping the most used pages.

- A small proposal was made for 10 hours a week for 3 months from a small strategic team. We gave Russell approval on that and talked about some plans and ideas.

- As a side note, Russell has been one of the most successful at pitching Steve and I projects, ideas, and concepts. We are excited to see what he can do in the next 3 months.

- Going back to concepts, we talked about some of the awesome ideas that Jonathan Wells has been working on, including building in the advanced search options right into the general pages. Easy exports and ease of use (in general). We also really like his idea of the education mode inside of the main adilas system or core. Able to turn the education mode on/off at the click of a button. Super cool idea.

- Lots of talks about rolling things up into aggregated totals and even doing our own data warehousing stuff.

- Moving our application into more business intelligence (BI) - having the system inform our users what is going on and help them make decisions.

- Tons of future projects. Never-ending refinements.

- User-defined carts and pages.

- The use of CSS variables to consolidate code and make things more efficient and usable.

- Lots of pitching of ideas, flow, concepts, and management styles. We ended by telling Russell that he could manage a small team over the next 3 months with a set focus on refining existing pieces and pages and communicating back with Steve and I. We are excited to see what he can get done. Good stuff. 

Nice little meeting between Steve, Cory, Russell, and myself. The main goal of the meeting was how and what priorities we have for Russell and his team for the next few weeks. They, some of Russell's team are in between schooling stuff and doing a small sprint for the summer months. Here are some of my notes from the meeting today.

- We went back and forth on cutting out or adding in the new cart stuff. We ended up cutting out the new invoice homepage to substitute in work on the general cart project. We know that it may not be fully done by end of summer. Small time frame but we know that we need it - eventually.

- Some of the other projects are: new invoice homepage, roles and user permissions, corp-wide settings, header/footer session values, etc.

- Russell spends a lot of time prepping the vision of where we are headed and where we are going.

- Lots of talk between the new invoice homepage and the shopping cart. We hit this subject multiple times. As some side notes, if we do the invoice homepage, we would also want to add new graphical homepages for expense/receipts, PO's, deposits, etc. Kind of a suite of graphical homepages.

- Alan's name kept coming up due to skill level and deeper tasks. He is one of the main assets and everybody wants his help.

- When it comes to time... it feels like there is a pull to either be a developer and doing development or being a project manager and helping others. It is really tough to be both at an effective level. It seems like a choice - either development or project management.

- We are seeing three new carts coming into play soon - Spencer - one-pager quick cart, Jonathan Wells and Kelly - smart cart - industry specific, and Russell - new generic and configurable cart.

- We are heading more and more toward mobile friendly designs.

- Keep moving the core system along. We want to keep working where our clients will be - help them by keeping the ball moving forward in a good and positive direction.

- There were some talks about help files and splitting things up. This could be smaller help files or actually making them more in-line where needed. Ideas about pulling them more into the page flow and showing things just in time, as needed.

- Education mode, videos, helping our users with smaller, in-line help, and options. This could even include tech support and online chat, per page.

- Use technology to keep solving the problems that keep coming up.

- Ideally, keep finding predictive ways of responding to needs.

- We were talking about Russell's small team of developers and options for them once Russell goes back to school. There will be projects enough and to spare... Keep honing in on their talents and skills. Let them run where they can. Good stuff.

- There was quite a bit of talk about smaller redesign projects and lots of form fields and in-line validation stuff. We could gain or get a lot of mileage by doing some small tweaks to the layout and forms, including in-line form validation stuff.

- Chuck could even teach a class on doing in-line form validation to help the other developers.

- We now have access to page level JavaScript and custom JavaScript per page. This is one of the new changes based on the projects that Russell and his team have already produced this summer.

- One of Russell's favorite things is dreaming it up and then really making it happen and function like we were dreaming. That is awesome! Real-time problem solving.

- Everything is heading to customizable and configurable - out of the box - that's where we are headed.

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.

Chuck joined the meeting and gave me a report on what he is working on. He has done a great job. Here are a few of the things that he is working on.

- New live chat feature for our main website

- Changes to the adilas docs project. Added a new training page, videos, new components and code, and working on some new education mode or bigger dynamic show/hide tool tips. We want to use some of those education mode pieces as we transition over into the fracture project (future project or future release).

- He showed me some progress on the presentation gallery and some alternate layouts. See attached for some screenshots.

- We finished up by talking about the WordPress back-ups and some light direction there.

Steve and Sean were talking about ecommerce and what is needed to keep systems going. Lots of moving pieces. After that, it switched over to a sales meeting. Steve was asking questions about some dealerships and recent contacts that Sean and Marisa were making. We talked about how much custom code is needed per client or per industry vertical.

We got into a conversation about the client facing scheduler and how cool it will be, but also how much code it will take to make it fully functional. The subject then flipped over to automation, wizards, settings, training, and education needs. As things get more complex, there needs to be ways of letting people know what is needed and what needs to be done. If the education is not there, it actually makes it even harder to figure it out. We talked more about ways of helping to speed up the training and onboarding processes. We need a way for our client to figure things out and/or be educated on what is possible and what is needed. Steve was mentioning that we need a balance between sales and new development.

As a side note, in some of our design prototypes for the fracture project, we were working on a better UI/UX as well as a thing called education mode (toggle on/off for extra help and information). The goal was to make it available but hidden. If it was needed, it was there. If it wasn't needed, it was hidden but still avaiable. Also, a good UI/UX will help eliminate some of the education stuff (not all of it).

The final topic of the morning meeting was dealing with advertising and pushing that forward. We also talked about having the best team we have ever had. Good stuff!

Cory and I going over a list of questions. About halfway through, Steve and Chuck joined us. I think that they were going to meet and work on some look and feel, but Cory and I were on the meeting. Anyways, the question got brought up about doing down payments on stock/units and how to book that and keep everything straight. The real answer is using transitional invoices. Having said that, we went round and round talking about possible options. Towards the end, Chuck was saying that when we redo our fracture stuff, we may need to make it part of the system that a prepaid invoice, deposit on merchandise, in-store credit, and other things be put in place and education and training made available.

For the record, here is how you would do it right now... using a transitional invoice.

1. Stock in the item, even if you don't have it in stock. If it is in stock, use that item. Anything that is unknown, just make a note of that. For example: a serial number or VIN number - maybe use the customer's phone number or email address.
2. Go to the stock/unit and go through the invoice/sale process. Make sure and set it to a transitional invoice (that wording is dynamic - layaway, prepaid, etc.).
3. Do the sale for the full amount and then take the amount that is either pre-paid or deposited. That will start the journey of the stock/unit and the payments received. All of these transactions will auto flow over to the balance sheet (already built-in) if using a transitional invoice.
4. Keep the invoice in the transitional state until it comes in, gets delivered, or whatever. If needed, additional payments (deposits on merchandise) may be made along the journey.
5. When ready, flip the transition invoice over to a real customer invoice and finish out the rest of the info. Once flipped, it will show up for sales taxes, on the P&L, accounts receivable (if money is still owed), and will count against inventory values. Prior to that, the whole thing is held on the balance sheet as the work in progress, pre-paid invoice, layaway, deposit on merchandise, etc. (dynamic naming).

Anyways, the takeaway is for fracture, we really want to have a way to show our people how to do certain tasks (searchable education mode). We also want to have some of the special account stuff like in-store credit, vendor credits, gift certificates, coupons, punch cards, etc. all done and part of the system. Those features may be built-in prior but need to be there. As a note, a lot of those will be sub sections of what we call special accounts, just like the current loyalty points stuff.

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.

Danny and Sean popped into the meeting. Nothing major going on but just talking about sales, demos, and how to put our best foot forward. We talked about getting small quick screenshots and samples to help go along with our demos. Currently, we bounce inside of a demo site, show someone around and then bounce somewhere else. I use the word bounce, and we are fine with that, but to a new user, that seems like you have to know a lot, in order to jump or bounce around. They want to know that we have certain things and want to get their hands held for the first little bit.

Because we are so flexible, it sometimes intimidates people and new users. That might be a good thing to remember for fracture (future project). Maybe setup a super simple step 1, 2, 3 process that always work (for example, the normal front door entance) and then show them how they can change that if they want to (side doors, back doors, basement doors, garage doors, etc.). Dustin was calling it handrails. I might be nice to have different training modes or education modes. If you turn it on, meaning education mode, it virtually tells you what to do. If you turn it off, you can bounce wherever you want (like normal). Almost an analogy of training wheels vs freeride or normal bike riding (without training wheels).

As a small side note, my dad (Wayne Moore) was saying the same things yesterday. We were looking at the main adilas.biz website and he was saying, I like the verbage but I want to see it (super tiny clips or screenshots). For example: It says "real time visibility and control with inventory management". Ok, what does that mean and can you quickly show me (a picture is worth a 1,000 words type mentality)? Just some quick screen shots.

As a note, there may be different levels. We may need a quick overview, a quick this is that (demo style), and then a deeper how to or let's really learn and master this. I can totally see a need for different levels of screenshots, examples, tutorials, and step-by-step walk throughs. Good stuff.

There were a few of us on the morning meeting. My internet kept dropping in and out. As we started the meeting, Sean and Steve were talking about 3rd party solutions and some of their needs. We are seeing a need and demand for better documentation of the adilas API sockets. We have them, we use them internally, and outside parties use them. We just need to keep giving that section some loving to really make it shine.

Steve asked me about my meeting with my dad and his friend Harry. I mentioned to them that they wanted to see rentals and reservations, as one of the first things that they wanted to know how to do. We can do it, but that too needs a little bit of work and automation. I will keep working with Bryan to keep fine tuning the elements of time and the rentals, reservations, and availability layers that we are working on.

After that, Steve asked a few code questions. He reported that he has been in conversation with some older independent adilas reps. They contacted him and may come join us, internally on our team. That would be cool!

John was showing the guys a demo of the new pages that he has been working on for new look and feel stuff. We talked about hiding some of the text in the forms and making it look simpler. As we were talking, we were telling John that some of those processes are very repetitive and once they learn it, they want to go as fast as possible. As a older side note, when we were working with Jonathan Wells, he had the idea of the education mode where you could turn on/off extra helper verbiage or helpers (handrails of sorts). Great idea.

It is amazing how fast GUI's or UI (graphical user interfaces) change. In a way, we and everyone else is competing with the big dogs as far as expectations and demands. That makes it tough. Along those lines, it would be really cool to gather more info on how our clients are using our system and what they like and don't like. We have tons of data, just no really way to process it and make an analysis of it. That would take a whole other person to really get in there and dig through settings, usage, traffic, choices, wants, needs, etc. That would be really cool but feels like one of those projects that is still out there a ways.

The last topic of the day was another plug for the datasource project and getting everyone on their own database (bus to motorcycle project). It has my vote as well.

Back to the main index for the master adilas plan

Master Adilas Plan - Jellyfish Model

Brainstorming Ideas and Topics:

- How big do you want to be? – See also the internal questionnaire responses and survey - tons of good info there - almost a mini plan by itself. Also, question 7 on the survey has a whole write up on the adilas jellyfish or jelly fish model and explains it further.

- The adilas jellyfish model - see attached - covers almost all of the departments and sub sections of what we are trying to be as a company. It is not the main product, but more of our internal and external departments, areas, and general areas that we will keep refining and working on.

- Possible numbers for the jellyfish model. Going from top to bottom and from left to right.
1. adilas.biz
2. Admin
3. Monthly Reoccurring Service
4. Sales & Marketing
5. Setup & Training
6. Tech Support
7. Design
8. Custom Code
9. Consulting
10. R&D
11. Project Management
12. Internal Development & Maintenance
13. Adilas University
14. Adilas Marketplace
15. Adilas Cafe & Community - Adilas World
16. Databases, Networks, Servers, & IT

Areas, sections, and departments in more detail:

** for me - go deeper into each section **

1. adilas.biz

• Are we going to stay the same entity? Are we the same or are we different entities? Are we rebranding? Are we piggybacking?
• What version are we on?
• Adilas.biz or adilas lite? Branding? Marketing? etc.
• The thing that keeps us all together is the reoccurring monthly services subscription for the main adilas.biz system. It has been the glue that keeps us together.
• Offering upgrades from ship A (current adilas) to ship B (fracture or adilas lite)
• What are our goals for ship A? What are our goals for ship B? Are we building it up to sell it? Are we going to be replacing ship A? How do you transition between the two.
• We want to make our current product better. It then grew into a full or bigger rewrite. It seems to be changing more and more. Originally, it was pretty small changes.
• Timelines to get things done? What will it take?
• Ship A will be great salespeople for ship B, once ready.
• If people change from ship A to ship B, there needs to be an increase or at least a re-evaluation of monthly fees and services.
• Ship B, we are planning for tiered pricing and dynamic billing based on functions, sizes, usage, storage, and preset packages.
• Ship B, they can toggle on/off different settings, include other features, and change what they want. All of this will reflect on dynamic billing options.
• Talking about future plans - selling it, royalties, secession, retirement, etc.

2. Admin

• The admin's role is to manage the budget, make decisions as to the direction that we need to go, do HR type functions, payroll, manage the different groups and departments, communication channels, general running of the day to day business.
• This could be one person, multiple people, a board, a council, etc. Somebody or some entity needs to be in control.
• Co-owners, Co-Founders, CEO's, presidents, vice-presidents, board members, etc. We can figure that out.
• If we do one person, we need to have VP's or managers in the other departments.
• One of our problems is that none of us (on the current team) want to be that person or take on this whole responsibility.

3. Monthly Reoccurring Service - aka Billing (new name)

• This is billing, invoicing, receiving, dealing with monies coming in and reaching out to our clients.
• Accounts receivables
• This could be tied in with admin roles
• Debt collection, bad debt, accounting, financials, etc.
• Setting up new corps (currently) and sending welcome emails and collecting business contact info.
• Bank reconciliation, paying bills, prep the budget info, etc.
• We could automate some of this, in the future.

4. Sales & Marketing

• We like that they are together. This is anything to generate and keep new clients to keep coming in and paying for our services. This could be publicity, knowledge about the system, get new demos, entice our clients to buy and keep buying from us. Serving their needs.
• Currently, the main method of marketing is word of mouth and referrals.
• We have used sales reps, consultants, and light networking. Steve and Kelly have been some of our biggest sales type people.
• We want to listen to what feedback they are bringing back. Currently, the sales people and the developers almost live in two different places.
• Sales should have a good pulse on what is working, what is not working, and what people and our clients are asking for. We tend to get lots of good ideas from clients. Sometimes, what that takes or the priority, that can get tricky.
• How big do we want to be? Get everybody or get enough (sufficient)? Keep pushing into other markets or be content with good ROI?
• Helping with market research, looking around and checking out markets, and what do we need to do to penetrate those markets?
• We almost feel like being in no man's land - too big for just a few people to push on it, not quite big enough to really have the team that we need to push it. Do we push and go bigger? Or do we trim down and keep it like it is (not really coasting but strategically developing as we can)? There are associated questions about speed, reliability, and uptime.
• Along with sales and marketing, there are expectations that are set and keep changing (trends and expectations).
• We need to know who we are servicing. Currently, we are kind of all over the place. We have little accounts, medium accounts, and some big accounts. We could go any direction. We just need to decide. Where is the sweet spot?
• If we want to be big and grand, we will need some major funding and thus major sales and marketing. Or do we figure out the sweet spot and really refine and focus in on things.
• Making things more stable and more reliable. Keep improving.
• We have a lot to offer - no one has even heard of us.
• The new and upcoming business owners are going to be fully connected and have certain expectations. If you want to get those guys/gals, you're going to have to revamp things.
• Our current mix is very developer heavy. We really need to switch that focus and get things that people want. Easy, Powerful, and Pretty!
• We need this department to really keep us in the know on what is going on. Currently, we don't have anyone fully dedicated or assigned to this department. We've been missing this piece.

5. Setup & Training

• Originally, we didn't charge for any of this. We just wanted people to get on our system. We are now charging for this and even trying to presale some of the training, deployment, and setup stuff. We are finding and have found, that people who get setup correctly and have the correct amount of training stay longer on our system. It has a learning curve, and that proper setup and training goes a long way.
• Currently, one of our system admin persons has to go in and create the corp, do a bunch of the settings, assign the master users, setup the logos and colors, and get them going. Most of that requires someone from our team to hold their hand along that process.
• Futuristically, we really want to help automate a bunch of that. Have them setup their own corp, let them pick what industries they want to play into, help them with their settings (wizard style), and then even help them pull in their data (without any other involvement). Let them create a test account or a free version, play around, and then either upgrade or get some help.
• Offer services to help our clients. Also have a number of self-help tools and features to let them do it themselves.
• We would love to develop a number of preset packages and industry specific skins.
• We would like the setup and training to be coupled with education and the adilas university side of things. They are very related.
• Getting products, customers, vendors, and other info into the system easily. Currently, we have to do a bunch of that (data imports) on a one-by-one basis. We need to make that more global and self-help level.
• Provide a good starting point to help them succeed. Show them the benefits and advantages of doing it our way or how we help them succeed.
• This department or division could include the adilas university, training, tech support, setup, and training.
• Easy access to get help and direction if needed.
• We see a lot of user error type problems. Figure out ways of helping them stay in their lane better or put up guardrails or bumpers to keep them on track.
• It has only been recently that we have added more focus on the setup, deployment, and training.
• This department could also include on-going training and retention. That is huge. Things constantly keep changing and we keep adding on new features.

6. Tech Support

• Currently, we allow people to email or call for tech support. It's free but often bleeds over into full on training, not tech support.
• We could build out a report a bug or open up a ticket or an issue. Make it easier to get support.
• We could provide better help files, tips, how-to's, videos, tutorials, and in-person training events.
• Everybody uses the system so differently, that makes it kind of tough. It would be nice if we have tech support stuff that was industry specific or catered to a specific industry.
• Tech support really should be part of the training, setup, and deployment stuff.
• Tech support could be a small carrot for deeper training and/or offering other paid services.
• Helping to show the value of deeper training and education.
• Having a standard way of getting to training and even industry specific training.
• Offer some adilas university training courses - covering various subjects on scheduled dates/times.
• Really helping to push the training and education stuff. Tech support should be quick, temporary, and non reoccurring. Show them the benefits of getting properly trained.
• As we move forward, we are planning on simplifying things. That should help with the training needs and the tech support stuff. Helping them figure it out on their own.
• If people (our clients) really want more tech support, we could offer more robust or advanced support packages.

7. Design

• This could be websites, forms, reports, interfaces, dashboards, UI/UX (user interfaces and user experience). This is the pretty and easy part of it. The powerful may be from a feature or backend process.
• Most of our current guys are developers, not designers.
• We don't charge enough, as such, we tend to skimp on the design phases and processes. This tends to get skipped or minimalized.
• We tend to do function over form - however, most clients say that they want function over form, but really, they want form over function - they want it to work and look pretty.
• Our project management tends to be a simple one liner. Do such and such. No other plans, requirements, mock-ups, or fixed specs exist.
• Mock-ups, prototypes, samples, wireframes, flow charts, graphics, videos, etc. We want to show the plan, air it out, and then build to the specs.
• Modern look and feel and user experience keeps changing. We need someone to keep watching and keeping up with trends, expectations, and options. This needs to be monitored and maintained regularly.
• Figuring out and sticking to a style guide. We do have a section called the "adilas docs". We have been working on it, but it has not been fully adopted yet. We need to set those standards and then stick to it. This is our style guide, and we are sticking to it.
• Doing some test cases and getting user/client feedback. How did their experience work out and what did we learn from that?
• Planning in maintenance and upkeep.
• Our clients squawk at things not being consistent. I don't mind change but I don't like some change and other things not being consistent. We could also introduce settings.
• We could allow the users, or corporations, to choose their default layouts. Horizontal forms, vertical forms, stacked forms, or auto formatted. We also want to store those settings and allow them to change it on the fly on per user basis.
• We need some consistency - this deals with who the designer is, what we are designing and outputting, people's preferences and opinions, and where we are heading. We can all be different, but we need to be consistent.
• Allow people to try things out and/or fully switch over.
• There is a point when we need to keep moving forward so we don't have to keep supporting all of the older styles and themes. Help make that as smooth as possible.
• We have some needs for design work out in ecommerce, customer facing sites, portals, and even business websites or web presence stuff.
• We need designers to help with marketing and social media stuff. Once again, consistency, specific plans, strategic campaigns, etc.

8. Custom Code

• This is one of the things that really sets us apart from other systems. We love it and even encourage it.
• We currently have tons of black box options. That was a solution at the time. There are some great concepts there (black box stuff) but we did run into problems.
• The code base keeps changing. We have had people ask for things, we build it custom for them and then wrap back and make it standard. The ones who got the custom version are now off on their own vs being fully integrated into the main codebase.
• We offer a lot of this. Having said that, we don't charge enough.
• We would like to move as much as possible to data driven settings and permissions.
• One of our current issues in maintainability. If it was on the side (like a black box page) it got left behind. The main pages always got updated but anything custom was harder to test, and harder to main it.
• If we do custom code, we need to build in some maintenance costs to help maintain that.
• We could do a community type approach - who ever helps build it out, gets a commission or a usage fee for others using it. Kinda like a sponsorship or something. We just need to get enough to plan it out, build it out, test it, market it, and then do some sort of kickback or reoccurring usage fee. There may be different levels  - one-time, reoccurring, built in, full one-off custom code, settings, combined projects (we pay, they pay, we then get to use it).
• Custom code should be by our internal developers and internal development team. We need to make sure that it works and doesn't affect something else.
• We have had some maintenance issues. Who made it, what does it do, how does it work, what does it touch, what else does it touch up/down stream, where does it live, how can you get to it, and was there any planning or testing done to the custom code? Tons of potential far reaching questions.
• If we build something... we really need to get an ROI and market those pieces.
• We could do some pay as you go build outs. Monthly fees that get added to their bill. They could pay upfront and then get a payment plan, or set it up on a reoccurring basis, or whatever.
• We need to charge enough. We often shoot ourselves in the foot. We charge pennies to build on top of multi-million dollar platforms and applications.
• We need good planning, good project management, good estimates, and then good developing.
• Estimates - take what you think it will take and double it. Then double that. It's almost a 4x ratio. By the time you add the work to get the work, the work before the work, the work, the work in between the work, the work after the work. It all plays in.
• Paying for both quality and speed.
• On the estimates, we also need to think about opportunity costs and what are we not working on, while doing custom code work.
• Approving custom code. Just because someone wants it... doesn't mean we should build it out. How does it fit with our mission statement, goals, and overarching plans and rollouts?

9. Consulting

• Byproduct of the main reoccurring business services. Once we are in, the system starts generating byproducts and people need to know what is next, how to do certain things, where they could go, options, next steps, phases, etc.
• We haven't really tapped into this yet. We do it, but we could do it so much more.
• This could be tied into the training, setup, and education stuff. Teaching our clients the best way to use the system to get the most out of the system or platform.
• You start getting into paying for knowledge and experience and expertise.
• We have seen many of our power-users become consultants. They know the system, they know how to make it run, sing, dance, and play. That provides a value to others. Those people then offer their expertise and know how to help others.
• Currently, some of this is done on the side. Adilas has no part in it, and no kickback exits. We would love to bring this more inside but that takes money to keep those people on call or on staff.
• This could be a great thing to add to the adilas marketplace.
• We may allow some outside stuff to go on, but we need some rules. We could configure this any way we want, we just need some rules.
• This could be part of the adilas cafe scenario - our clients seeking out a professional to help them out.
• Do we want to manage this internally? What would that look like? Once again, we may need some rules here.

10. R&D

• Research and Development - You have to spend time here to move the ball forward. If you aren't going to move forward, nothing will happen, you will live and die. You have to keep up, especially with tech stuff.
• Exploring different avenues - there are costs for exploring.
• Cutting edge, bleeding edge, sweet spot, new ish, or older/classic?
• How much does it cost to be on that cutting edge?
• Vision, plans, and looking to the future. Where are we/you heading? Plans, how are you going to get there?
• It really comes down to where do you want to play (on the spectrum)?
• Training what is new.
• Maintenance for what was or has been developed. Technical debt.
• Stable and known or less stable and new - How quick will the older pieces change and/or be deprecated? If it's so new, it may not even stick.
• We make things and then it sits on a shelf. That hurts. There could be difference between development that didn't get fully funded vs totally new prototyping and experimenting.
• Is this something we should do? On not? Figuring out what it takes to make something happen.
• Looking into speed, efficiency, demand, cost analysis, needs analysis, scope, scale, and reality of doing certain things.
• Beta testing, prototypes, experiments, testing, pushing boundaries.
• Currently some of our R&D is mixed in with our code. We try things to see if it works. Without being consistent with other pages and code. We often have good intentions (prepping for the future - mini stubs or prepping for stuff) but then get pulled on to other projects. We do a lot of experimenting within our projects. Almost a revolving door or revolving code set. Basically, a fully working, living prototype.
• We are seeing a mix between custom code, R&D, and project management.
• Back tracing or reverse engineering things. Sometimes if you know what you want, you can then figure out a way to get there, that might be easier or better.
• Being aware of what's out there? How could I use some of that in my projects?

11. Project Management

• We have really been missing this piece. We do a ton of just in time project management. We are not very good at doing a more full design, plan, or architecture type layout.
• We do a lot of this one-on-one right now. One project and one developer.
• The project manager can and does act as the shield between the client and the developer. Buying some time or deflecting decisions.
• They help with quotes, estimates, and project specs, scope, costs, timelines, and details. Lots of potential back and forth communication is needed.
• We have spent a ton of time and money going back and fixing things that should have been planned out originally. We have also spent money where a developer makes a decision and just does something and doesn't ask or doesn't get any clarification.
• Teams - authority, accountability, and responsibilities - setting up clear expectations. We have played around here a bit. We need to refine things here a bit, based on our needs. We had some people who were so worried about how to do scrum that it didn't actually happen. We also had some problems with free riders. We want to use some small teams, but still need to get it refined a bit better.
• Dealing with teams, we were trying to do some training... and we didn't really have it all defined. Wasted time in meetings, talking about code, and what is needed. We then fall down based on assumptions or just verbal communication. It needs to be just a little bit deeper and more consistent.
• Team sizes and dynamics.
• As a project manager, not assigning yourself to a required task. Actually, make an assignment to do the project management.
• Someone needs to be available and be the virtual babysitter. Getting rid of hurdles and what is expected of them. Helping them stay on task/track. The project manager's job to help other people succeed.
• Slowdown
• We build and build and build... we need to slow down and test it, train on it, market it, and push it.
• Being able to plan it out so that we can reuse as much code as possible. Giving the developers guidelines, handrails, samples, and good instructions. If it's too tight, they don't want to do it (it takes out the fun of figuring it out). Figure out what developer needs what (how detailed) and then play accordingly. Developers need to accomplish something. Not just follow A-Z and you're done. It is a mix and a spectrum.

12. Internal Development & Maintenance

• This internally funded by adilas to work on adilas. This comes from revenue and budgets to keep the system up and running.
• Bug fixes, maintenance, changes, next steps, phases, testing, documentation, code review, etc.
• This needs to be tied into project management and custom code.
• This is the most defined area that we have inside of adilas.
• We get a plan from project management, we then build it out, test it, deploy it, and make sure that it works.
• We have had problems with guys following style guides. Everybody has their own ideas on what a good style guide is. This could be whitespace in code, tabs, naming conventions, etc. It also happens on the look and feel part of page or report.
• Alan had the idea of having a way of helping to force or standardize the output. Almost a forced style guide or validator of sorts. It all has to comply to a certain standard. Whitespace, naming conventions, comments, indents, variable names, components, etc.
• Keeping things separated - backend, database, objects, services, views, logic, functions, classes, etc.
• In object-oriented programming, you need good encapsulation (only contains what is needed) and low coupling (lower number of steps as possible).
• There is some great value in teams and getting different points of view. A better solution because we worked on it as a team. More well-rounded.

13. Adilas University

• This goes hand in hand with the training and deployment section. This is the training arm of the system. It may also tie in with tech support or consulting. We could combine some of this as needed. Similar type people and knowledge resources.
• General topics for training - One, how do you use the system? Two, how do you run your business? Consulting is a part of this as well - what are the best business practices and how to get the most out of the system.
• There could be standard stuff, custom stuff, and internal stuff.
• Each page would have how to videos, quick videos, and options for more or deeper training.
• We also need to offer some custom or live training events.
• For fracture, we experimented with a thing called the education mode. You could turn it on/off and the system would hide or show more options and information. You could turn it on from any page and all of sudden it would react differently. We have some great screenshots on this from Jonathan Wells. Along with this, the help files could be shown, side-by-side with the page that they are referencing. There were also options to toggle into the actual adilas university site as a tab withing the side-by-side help window.
• There is a known missing gap here on the education and training side of things.
• There could be free levels, basic stuff, and deeper more paid type levels of training and consulting.
• There could also be certification levels, requirements, status, and other testing and certification stuff.
• We are hoping that the adilas lite and fracture project will make it even easier to help train the users and because they can tweak everything, there will actually be less of a need for certain pieces of the education and training. They will still be there, just hidden as needed.
• This could be a whole other business entity, if needed.
• A new user really wants to be guided through - holding their hand. An advanced user may not want any of that stuff in their way, just let them do it quickly.
• Link to this from the adilas cafe.
• If we do certifications, maybe show or allow some of that basic info to show to other users, if they are seeking trained professionals to help them out.
• If we have trained users, those become a value to others who are looking for help or pros on those topics.
• Adilas University could be a stand-alone product, or it could be interwoven with the entire site. Both have the same content, they just either have a standalone navigation system or we help navigate for them based on what page the users are on (context stuff).
• There could be levels to the training... Think of a triangle - simple, basic, intermediate, advanced, and deep or backend logic or design level stuff.
• There may be both external and internal training pieces. Along with that, we may have to have permissions or something that open/closes those training modules for certain people or parties.

14. Adilas Marketplace

• Part of the adilas cafe. People could sell their products and services, buy products and services. Including adilas skills and other professional skills.
• Adilas creates lots of byproducts. This is a way to help harness and gather up those byproducts. 
• Options for 3rd party solutions, white labeling, advertising, marketing, etc.
• Online mini marketplace for adilas products and/or our users could sell their products and services on a mini Amazon or eBay type level (mini consignment type shop built for our users and companies that use our products).
• Possible payment solutions with interest, fees, commissions, and other small kickbacks for using the marketplace.
• Limitless potential for other byproducts and additional services that could be added on to this piece of the puzzle.
• This may need a separate team to help run, manage, and administer this piece of the puzzle. Automate as much as possible.
• Here is a rough draft - Russell did - way back - don't get stuck here... It could be so much more. Adilas Market

15. Adilas Cafe & Community - Adilas World

• A landing spot outside of any corporation or entity.
• A corp selector - where can I go (have permissions or access)?
• Get to the marketplace type stuff.
• Get to the adilas university stuff.
• Forum type stuff - ask Q&A type stuff. This could be answered by staff and/or other users. This would need a moderator or forum manager.
• Let people show that they have the skills that others (businesses and/or individuals) could be looking for. This may include direct messaging or some other way of communicating.
• White labeling options.
• Standardized portal - single sign in be able to jump between servers and corporations.
• Dynamic billing and making payments.
• Mini marketplace for adilas products.
• Sales and creation of new accounts - tiered pricing and auto setup options
• News and updates - configure news feed as needed.
• Interface with other companies and corporations. Get assigned, hub type model.
• Work, play (demo sites), buy, sell, training, social stuff, and participate.

16. Databases, Networks, Servers, & IT

• This is the whole backend of the application or hardware side of things.
• Load management, reliability, up time, speed, redundancy, backups, storage, orchestration, etc.
• Lots of security needs and requirements. They will also be majorly involved in implementation of security.
• Code interacts with these things, but they are separate entities or divisions.
• We will need our own documentation, permissions, training, etc.
• Maintenance and upkeep, prototyping, standardizing, testing, databases, servers, hardware, clusters, network, security, IT stuff.
• Patches, updates, protection, hacker prevention stuff.
• Email servers, text or communication servers, web servers, database servers, backend logic servers (ColdFusion or whatever).
• Monitoring services, requests, traffic, load balancing, stats, specs, remote access, database indexing, automation scripts, tons of IT type stuff.
• Migration stuff, off-hour updates and maintenance, backups, restores, and other tasks.
• Move data around, put things into and out of cold storage, special bulk data manipulation stuff, zip and archiving things, etc.
• Future proofing things.
• Offloading bigger or longer processes.
• API sockets, API endpoints, and being able to load balance traffic, requests, deal with sessions, server config, clustering, and managing small microservices.
• We need a way to get rid or purge some of the pieces. The current system builds and builds. It never really releases or virtually poops (dumps).
• We would love to get a full data dictionary to allow our new frontend to be more data driven.
• This could be multiple people - DBA, IT/Server guys, etc. They could cross over, but these are high level skills and high level people or teams.
• Everything on the hosting side of things. This gets deep but just think - what do we need for hosting? - SSL's, domain names, hard drive space, spinning up servers just in time, pointer records, DNS, DSN, puppet, orchestration, bit bucket, code repositories, ColdFusion Administrator, Fusion Reactor, Papertrail, Nagios, tons of outside services and tools.
• Servers - hard drive sizes, backups, RAM, CPU's, configs, and the list goes on.
• This could go deep and deeper... Etc.

-------------------------

- Alan and I were playing with a mini version or what that might look like (see attached for a mini mock-up of the smaller mini model):

Adilas.biz - admin, monthly billing, and day to day running the company. They could do their own R&D (progress, speed, what the clients are wanting).

Sales & marketing - They could do their own R&D (advertising, pricing, features, marketing materials, etc.).

Consulting, tech support, setup & training, and retention. This could also be part of the adilas university (similar folk). They could do their own R&D (tied into sales, marketing, training, etc.).

Development stuff - project management, custom code, internal development, maintenance, & design. They could do their own R&D (code, frameworks, layouts, look and feel, etc.).

IT stuff - Databases, servers, hardware, hosting, etc. They could do their own R&D (speed, load balancing, redundancy, monitoring, etc.).

Marketplace and adilas cafe - This could be their own little piece or small team. They could do their own R&D (product research, options, pricing, hardware options, services, etc.).

We would love to see each of these sections or divisions (departments) be able to meet and interact with each other on a consistent basis (at least monthly or semi-monthly). Nobody is left on an island by themselves. Communication is huge.

Sean and I started out the morning talking about deployment and how we need to keep offering that as a service. Certain clients are so busy, they really don't have time to deploy or devote time to training and setup. It's not that they don't need or want it, they are just spread too thin. Sean was talking about a current deployment that he is working on and I told him a story of us going into a kitchen ware store and helping to set them up. It took a couple of weeks with a few of us onsite to make it happen. At one point, the lady in charge of the kitchen store said, "If it wasn't for you guys helping us out, we never would have been able to make this transition." That is totally true.

Anyways, I wrote down in my notes that part of the fracture project that we are planning has to take into consideration training, deployment, setup, and other marketable services. We need the support staff to help support what we are trying to do, build, and accomplish. Taking the time to get it done and make sure that the parties that be are in the know and can function on their own. They need to know how to get help, but ideally, they have been trained sufficiently for the task(s) at hand. Another plug for the concept of "education mode" as a setting for helping people to get started.

Steve was on some phone calls and somewhat listening in the background. Sean and Shari O. were talking about merchant processing and where we want to go with that. I mentioned the company Datacap and let them know that we may want to look into doing a 3r party integration and solution with them, as it would open up a number possible merchant processing options. We can do merchant processing right now, but we have to spend time and resources integrating with each gateway, merchant, and/or device. We could really use something to help speed up that process.

As the meeting ended, I was doing emails and other small to do list tasks. I was thinking about small nursery rhymes and how we have used some of those same analogies and stories in our own story. Things like stone soup, the little ren hen, and many others. Kinda fun. We are daily building and hoping that someone will catch the vision and help us along the journey. Like the tortoise and the hair, slow and steady wins the race.

New transition today. I popped onto the morning meeting because that is what I normally did. I let the guys know that I wasn't going to be doing that any more. Sean was on the meeting and we chatted for a bit. By way of an update, he is doing great working with the dynamic adilas label builder. He is also willing to do some checking out of what our competitors are doing and providing me some competitive research. Nothing too huge.

John joined the meeting, and we were looking at some mock-ups. We would like to allow our users to interact with options to setup their own space, look and feel, etc. We would also like to do some early prototyping. Get it out and in their hands. Even things like settings for click vs hoover and other simple choices that affect their space (what they do and use - their space, their flow). We already have a bunch that we have paid for and haven't been able to use it yet. We have a ton of R&D stuff that Jonathan Wells did in Adobe XD for fracture, adilas cafe, and a new shopping cart.

A picture is worth a thousand words. Dramatize it, push up XD docs from Chuck on the content server. We have done tons of really cook R&D. Let's use that. This is how we are going to get fracture up and going and off the ground.

John and I talked about trying to centralize all of the data and assets. I have a bunch of it. We have pushed up a bunch to the adilas content server. We also still have quite a few assets and raw authoring files with the guys/gals who made them - Jonathan Wells, Chuck, Russell, Marisa, etc.

As part of our discussion, John was showing me some of the projects that he worked on for school. He's got business design docs, pitches, proposals, flow charts, etc. I'd like to tap into some of those planning and system scope documents. Not necessarily for his project, but more for what we could do for our projects. Once again, show them don't tell them. That is huge and reoccurring theme. Show them, don't tell them.

Here are some other notes from our meeting:

- We could make some awesome customizable dashboards

- Realtime data on what is going on (tables, graphs, charts, and quick aggregates), help them see everything without overwhelming them. Full visibility.

- "Show them" and then do it over and over again.

- Talking about dream salaries between John and I. Where would you like to be, salary wise?

- Keep idea farming - that's what we do

- Shari O. joined the meeting. She loves to do some gaming. I'd love for her to come up with some ideas on how to turn adilas and the daily work into a game of sorts (the game of business). Shari O. said that she could do some light research and maybe come up with some ideas. As we were talking, she said that she changes games based on moods. That's good information. We may want to come up with something similar - what mood are you in? Ok, let's play that way. This is just a dream right now. I'd like to see where it goes.

- Keep gathering things together. Eventually, we will make our own world.

- More ideas for the application and/or system - education mode, game mode, nuts and bolts mode (just get it done - speed mode).

- More talks with Shari O. about Facebook groups, other social groups, having meetings, setting up schedules, and giving people power to run what they want to do. Make the whole thing a team effort.

Planning with Aspen. Doing some brain mapping on a huge board with post-it notes. See attached for some pictures. Lots of high-level planning for adilas lite, fracture, and sub projects within our bigger vision. Once again, see attached. We also got Aspen paid for her work.

Quick breakdown of the different projects:

#1 - Company Structure - Jellyfish Model - Knowlege workers vs hourly workers, define divisions, departments, the who (talent), combine areas as needed, optimize structure, overtime, and compensation. We also want to deal with the different personality types - organizer, doer, creative, consultant, and the salesperson (someone who does sales).

#2 - Product Development - Value Add-On Core - Players, features, each summarized (possibly in a video or multiple videos). Define the current core. Figure out industry specific skins. White labeling options. On the industry specific skins, go minimal for the start. Custom code - data driven, not code driven. BI (business intelligence) level - Model needs to be fully planned out because it doesn't exist as a standalone layer at this time. It is built into the system as a whole. We need to extract those pieces and make a better plan for those numbers, values, and pieces of BI. Enterprise - define it and prep the database to make the jump eventually.

#3 - Education and Training - Adilas University - Internal and external training needs - video clips, organize them (library of sorts), tracking education, SOP's (standard operating procedures) per industry, in general, and company specific options. Make all of this data driven. Easier interactions, easier interface, all dealing with settings (show/hide, rename, aliases, sort order, defaults, etc.). Once again, both internal and external training needs. Online and in person trainings. Minimize the need for education by building out a better interface (fracture and adilas lite). Dynamic content and settings. Program education directly into the interface. Be able to turn the education mode or help mode on/off based on needs and per person.

#4 - Community and 3rd Party Solutions - Adilas Marketplace - Access from the adilas cafe or as a standalone app. Adilas creates tons of byproducts (both products and services). This could be things like consulting, design, custom code, data entry, bank reconciliation, accounting needs, etc. We want to offer ways to both buy and sell both products and services through a controlled interface. Think of a mini Amazon or mini eBay type marketplace. We need a spot to send, organize, and direct 3rd party solutions. Advertising and marketing efforts. More white labeling options (in the marketplace). This section could be further explored and has lots of potential.

#5 - Social and Efficiency Options - Adilas Cafe & Community - White labeling, standardized portal, single login, single sign on, able to jump to any corporation on any server where permissions have been granted. Options for work, play, buy, sell, train, social, and participate. User profile page. Interface with other corporations, get assigned, hub type environment. Mini marketplace for adilas based products and services. Sales and creation of new accounts (automated setup options). Tired pricing. News and updates, this wouldn't be forced on anybody but would be more available. We could allow them to customize their news and update feed. Dynamic billing and making payments for our (adilas) clients.

#6 - Deeper Product Development - Adilas Lite or Fracture - Customize everything. Setup wizard, question to help with setup, industry specific settings and presets, sizes, features, and options to customize as needed. Show/hide almost everything. Other settings such as toggle on/off features, columns, reports, navigation, etc. Everything is configurable to some extent. Sort orders and the ability to move things around (vertically, horizontally, and free form). Settings and making all of these decisions data driven.

Inside of fracture (code name before we got adilas lite) we want to make some server changes, code changes, frontend and backend changes by using frameworks and different languages (code stuff). Entirely composed of API sockets. This will make everything more portable and will also allow other outside developers options to build custom pages, features, and interfaces. Another advantage of using the API sockets for everything, it will standardize how everybody interfaces and interacts with the system or application. It will also let other developers play along without letting them see the underlying code. They just see documentation, examples, and final output from the API socket calls or API endpoints.

Fracture will include testing plans, sections for unit testing, integration testing, automated tests, and good coverage on testing in general. Everything will be modularized and broken into smaller mini components. We plan on using dynamic billing for usage, features, storage, etc. Entirely new interface with the ability to setup your own navigation and your own dashboards. We want lots of white labels and white labeling options. Tons of industry specific stuff as well.

Be able to turn on/off the education mode. We would love to capitalize on numerous lessons learned from 20+ years in the business. Lots of prototyping, new databases with good indexing and normalization. Directly program in teasers and marking. There has even been some talk of using AI (artificial intelligence) to help with suggestions for products and features that they might use or want.

Everything will be mobile ready and responsive. Client-side and server-side validation. We also want to prep things and have a maintenance plan in place as well. That is something that has been somewhat missing from past versions. Basically, take what we have and build from there - learning from the past and building for the future. Everything has a life cycle, prep for the next phase or part of that life cycle.

#7 - Budgets, Finances, Marketing, & Sales - Other business plans - interactive wireframing presentations, SWOT analysis, funding and repayment stuff, timelines, mission statement, profit sharing, budgets per section, per person, per product/feature. Writing business proposals, project scopes, sales pitches, standardization, and master table of contents. Lots of good marketing and campaigns for sales. Sources of profit and ROI (return on investment). Prototyping, testing, and market research.

#8 - Other - Networking and meetings as well as more research. Get in there and get it done!

Emails and texts back and forth to John about the adilas cafe. Working with a document for Danny and YouTube training videos. I then met with Danny and we went over options for some of the videos and training assets that we both have and/or need. Danny and I were talking about things, and he was saying that he knows a company that doesn't even release the next changes until the training is ready, done, and up for viewing. See attached for a screencap of what we were talking about.

Here a couple of the links that I sent to Danny:

- Entries in the developer's notebook talking about YouTube videos - lots of good resources. Once it comes up, do a browser search for the term "YouTube" to help pinpoint some of the options.

- Entry in the developer's notebook talking about a thing called education mode.

As a side note, on 8/14/23, I added this little link to a video on the education mode.

Pulling out some new sample videos from the XD mock-up files from Jonathan Wells. See below for details.

- Overview of the education mode - Length 00:01:54

- Overview of the adilas quick search - Length 00:02:49