You don't read right to left, but you should plan that way.
This concept is especially important for projects that are less straightforward. Projects with high complexity and less-traveled paths are more likely to become obscured during development. Miscommunication, scope creep, and a failed outcome are more likely to happen when the finished project can't be visualized and defined.
I find that drawing on a whiteboard/paper helps visualize this step, and highly recommend it. Drawing your forms and visions can go a long way in communicating your vision to a developer.
This article applies to all configurator implementations. My projects using Solidworks Add-Ins, DriveWorksXpress, Autodesk Inventor Add-Ins, AutoCad Add-Ins, and iLogic all start with this discussion.
At the end, I'll go into some more Right-To-Left philosophy and make some wild assumptions, be sure to check that out.
Overview
In this article we will define the following:
Jump To Conclusion - Organizing Complex Projects
Project Output: Purpose & Form
Project Output is exactly what it sounds like: The files and information created and saved once your configurator is ran.
Some questions to ask:
Where will final output be used down the line?
Manufacturing Prints: Probably the most common type of output we see. Think about what info has to be on your prints, and how they will be accessed. Do they need to be reviewed? Will there be changes made after being configured? How will they be accessed for manufacturing?
Quote/Approval Drawings Is your product being configured for an RFQ? Need an approval drawing? These are common uses for configurators.
In other assemblies Configurator factories often output many "library" parts, and need to be made in a way that they are most compatible with their future parents.
CNC Code? Becoming more common, some customers are using 3D and 2D CAD information to assist in the creation of G-Code on the shop floor.
What form is the final output?
CAD Files Files that can be opened/edited by users with CAD software
PDF/DXF Universal file formats that can be accessed by virtually anyone.
File Locations? Think about how files will need to be accessed and how they need to be interacted with. Think of a consistent location for both source and output files. A little organization goes a long way here.
Will output files be reconfigured? Will the files need to be changed by the configurator, or do they just become a normal part that can be edited by users through manual procedures? Reconfigurable parts should be used sparingly, as they are inherently less stable when being configured inside of the CAD environment.
Project Users
Users are an important aspect of your project planning. Everything part of the development hinges on knowing who the user is, where they are, and how they will use the program.
A few questions to ask:
Who is the user?
Are they inside your company? Do they have CAD software? Building a configurator for users that do not interact with your CAD software can be a little more complicated, but not impossible. Users can interact with Excel, or other input forms to submit information that can be configured.
How well do they know the product? Inputs/Forms are designed with a target audience in mind. An engineer might want more control than a Sales rep. Knowing your users level of product knowledge is important.
Where will the user start?
CAD System More specifically: From the "Get Started" screen? Any open Assembly? Only a specific Drawing file? How about only when editing a sketch? Think about the most natural place that a user will be when a configuration needs to happen.
Excel/ERP/Salesforce If users are already in Excel for quote or engineering info, it doesn't make sense to have them copy the info to a CAD tool. Import Excel/Epicor/Salesforce data with one of our translators.
Desktop Some CAD systems allow external programs to update properties of CAD files (IE: Autodesk Inventor Apprentice). Functionality is typically limited
The Web Cloud solutions are becoming more popular, but are still one of the most expensive implementation options. We typically stay away from cloud solutions unless configurators need to be accessed by a very large number of users. Look at: Autodesk Forge
How will users access the inputs?
Buttons We all love buttons. Add them to toolbars, taskbars, different tabs, really anywhere. Buttons can have customs logos and names, and come in different shapes and sizes.
Menu Panes Menu Panes can be pinned and allow info input or reference info with little navigating from the task at hand.
Right Mouse-Click on point/part/feature/line? RMB menus are a fast and sleek way to perform operations on individual objects.
Inputs
Some Questions to ask:
What info will we know at time of input?
Parent Document If the assembly or drawing that a configurator is being placed into contains information, we want to take advantage of that. IE: a custom iProperty in an assembly contains the customer's name. We can use this value and write it to our output files without prompting the user to retype it.
Existing Excel/Database/Text Retyping information is a source of errors and wasted time. Most CAD software can import information from various sources programmatically.
What info should the user input?
Info that can't be calculated Every time an input is designated, you should ask if the input can be calculated from another value. Creating strict design rules will decrease the number of different configurations created, errors at input, and wasted time.
Are there reference points that need to be virtually selected? Users can be prompted to select anything that can be seen in their CAD window. For example, placing a new pipe fitting might require a user to select a concentric reference, as well as an end plane to complete the constraint.
Information Presented to the User
Sometimes while configuring, Users may need to manually alter, or reference information for their design decisions.
What info should the user be presented?
Mass/Material Properties Common for users to alter or reference
Generated BOM BOMs can be tricky. Are there any manual edits needed for a BOM? Maybe an export? Or even just a review.
Calculated values Showing calculated values to a user can add another chance for review during configuration. Especially useful for engineers.
Cost Cost can be very beneficial to present to a user for ETO (Engineer-To-Order) configurators. If generating a quote via configurator, cost adjustments could also be made.
When should info be presented?
Before or after finalizing changes? With some configurators, there is a point of no return. Should we present info before so we can "alter the future" before it happens, or will we try to change things after?
Should the user be able to manually change info? Can the user change presented info, what info can the user change, and will it require configuring models again?
Conclusion - Bonus: Organizing Complex Projects
Wrapping things up, there is one last concept I wanted to throw in. We started with the concept of working Right-to-Left, but I want to alter the way we think of Right-To-Left, and change it to Outside-To-In. I'd like to challenge the reader to some abstraction.
Earlier I used the example of placing a pipe fitting in an assembly. Let's say there are 10 fitting types, and each has at least 3 unique inputs. This means we are going to spend a significant amount of time designing a UI that can accommodate 30 unique inputs.
If a user has to design a pipe run with 20 fittings, they must open a configurator, and configure 20 fittings. Every time they configure, they have to wait for all files to finish copying and inserting and saving. Now, we were probably smart and put some logic in to automatically constrain the fittings as they are placed, and used some default values between the fittings, but our user still had to run the configurator 20 times.
Now, the automation Add-In is complete and does what we asked, but I'm left wondering if we could have gotten a little bit more. Maybe we should have stepped back a level. Instead of creating 30 inputs, I could have defined my pipe run with 5:
Start Point, Stop Point, Pipe Size, Fitting Thread Type, Pipe Type.
Now that I've saved some development time, I'll use that time to make some super-cool pipe run algorithm that avoids running into other objects, and follows company standards.
To finish it off, because we designed this tool to be used this way from the beginning, we can batch process all 20 fittings and perform all of our intense operations virtually (behind the scenes). This means the user waits for less time, one time to generate an entire pipe run.
Now, we're done, and that's probably pretty cool, but I forgot that every one of my final products has 10 pipe runs.. And you probably see where this is going. I'm not saying that you have to design your configurators all at once from the top down, but you should plan them that way. If the developer was aware that you wanted to eventually configure an entire run, they could create your object library in a way that was more accepting to that workflow. Knowing the final outcome would save a lot of time in the future, and ultimately make sure your investment is still benefiting you for years to come.
If you this content helped you out, please share, and consider subscribing to our newsletter for more information.
In our next blog, we'll Plan An Object Model Library for our Project and go over the next steps. Subscribe below to get notified when it is released!