There are several ways to look at the application development process. First, we’ll look specifically at how to think about the application Design itself. After that, we’ll look the bigger picture.
Application Design
For the purposes of this section, we’ll focus on the core application Design. In reality, especially for bigger Projects, it is important to follow a more comprehensive methodology like the one we describe in the next section.
The first step is to make sure that you clearly understand the requirements for the Project and bounds on the scope of work – what is in, what is out? Once you have that, below are some things to think about and work on before you start implementing.
Inputs
A key element defining any application are the input Parameters. The inputs drive the application. The range of values that any input can have determines the scope of the application. Additionally, it is important to understand the inter-dependence of the inputs. This will help to determine the sequence and style of presentation.
We mentioned the difference between a black box application and a gray box application earlier. All inputs have to be gathered for a black box application. The application then can be run to create outputs. For gray box applications, the application is necessarily interactive, and initial inputs have a significant impact on which other inputs are needed later in the process. Often that interactivity manifests itself as graphical interaction – that is, point-and-click selection, layout, drag and drop, etc. It is important to understand the interdependencies between inputs to be able to Design the user interface.
Outputs
What are the outputs for the application? Possibilities are:
▪Models
•3D
•Schematic
▪Drawings
•Submittal
•General Arrangement
•Part
•Assembly
•Manufacturing
•Field Assembly
▪BOMs (Bills of Material)
▪Price
▪Weight
▪Quote
▪Proposal
The Rules that you develop simply have to connect the dots between the inputs and outputs.
Top Level Design
How are you going to organize the tree? Although we generally think of the tree in terms of assemblies, subassemblies, and leaf parts, there is no automatic requirement to organize the tree that way. And even if we do, there may be more than one way to do it.
For example, let’s consider a house. One way to organize a house Design would be to have a root object, house, then have each room as a Child under that, and then everything in the room under each room node of the tree. This is what we refer to as geometrical organization of the tree.
Another way, however, might be to organize it by function. In that case, maybe the house is organized with house at the root, then walls, plumbing system, electrical system, and HVAC system under that. This is a functional organization of the tree.
Neither approach is right or wrong. The question is, which will make writing the Rules and supporting them easier?
In the geometric organization, geometry is going to be easier. In the second one, managing the functional Rules will be easier. In general, you want to Design the tree so that it will minimize the length and complexity of the reference chains. This will increase modularity and reduce maintenance headaches due to broken reference chains if you ever make changes to the tree.
In general, we have found that there are far more geometric Rules and they tend to be more complex than the functional Rules. So, we usually organize our trees based on geometric relationships.
Another thing to consider is that the tree can represent far more than just the product that you are representing. In general, the Rules have to also represent the user interface, the outputs like drawings, quotes, BOMs, etc. To keep track of all this, we often organize the tree with a root that represents the entire Project, then first level children organized like this:
Supporting Library
It often helps to think about the library of building block Designs or Mixins that you can build at the start of a Project that will serve as the foundation for your application. Often, these may be separated into their own Project and used on their own, thus providing nice modularity and reuse.
•Building Blocks
oThese are parts or assemblies that can have re-use across your applications
oIf you think of a cabinet application, building block possibilities include
▪Hardware – hinges
▪Feet – casters
▪Shelves
•Mixins
oAs we mentioned in the section on inheritance, Mixins provide a great chance to create reusable content. When more than one part will have the same Rules, it makes sense to abstract those Rules into a Mixin. Thinking through what the Mixins might be, and how they will be created and used is a great step toward building a successful application.
Database
Most applications will require at least one supporting database table, and most applications will have many. Thinking through what those tables will be and how they are organized is an important step in the planning of your application.
NOTE: The concept of normalization is beyond the scope of this overview, but if you are building large and complex database tables, it is a worthwhile concept to study – or get help from an expert.
Tables are often used to define the valid choices for pull-downs in the UI. Database tables can also include lists of materials, colors, properties, etc.
When coupled with a building block Design, tables provide a great way to implement catalog-type parts. For example, you may define one kBridge part that represents the geometry of a bolt based on its diameter, length, thread, head-type, etc. If you couple that building block Design with a table of available bolt sizes, now you have a complete library of bolts to use for your application.
Admin Tools
Closely related to database tools, administrative tools (Admin Tools) can make your application much easier to maintain by folks who are not technical and may not know anything about kBridge. In the example above of a bolt building-block part coupled with a database table of available bolt sizes, we can imagine an Admin application that simply shows the user the table of bolts and allows them to add, modify, or delete entries. This can be presented in a very simple way that is easy for any administrator – even one not trained in kBridge – to maintain the database table. When this has been Designed as a smart library part, it will automatically pick up the changes and make them available in the application.
Integrations
Another key element to consider when planning a new application are the required integrations. Many integrations might simply be available in the kBridge App Store. This includes
▪Autodesk Revit
▪Autodesk Inventor
▪DWG / AutoCAD
▪Microsoft Excel Integration
▪Database Integration
You should explore the kBridge App Store for new additions that might cover your requirements and shorten your development time.
Other integrations will need to be implemented using the kBridge API. This needs to be considered carefully since the capability of the integration will be critical to your application.
