> For the complete documentation index, see [llms.txt](https://docs.amltd.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amltd.com/dc-works/core-concepts/dc-works-design-best-practices.md). # DC Works Design Best Practices Well-designed DC Works solutions are easy to understand, efficient to use, and reliable in the environments where they are deployed. The following practices provide a foundation for planning and building effective Applets and Suites. ### Start with the process Define the real-world workflow before designing pages or selecting fields. Identify: * What begins the workflow. * What information users need. * Which decisions must be made. * What information must be stored. * What indicates successful completion. The Applet should support the process—not make the process conform to the interface. ### Plan the data first Determine which information must be stored in tables and which values are needed only temporarily in local records. Use separate tables for different types of information when appropriate, and choose clear names for databases, tables, fields, and records. {% hint style="info" %} Plan the workflow and data structure before investing heavily in page appearance. Changes to tables or records may require corresponding changes throughout the Applet. {% endhint %} ### Keep Applets focused Each Applet should generally support a clear task or closely related workflow. For example: * Receive inventory. * Perform a cycle count. * Check an asset in or out. * Complete an inspection. * Look up product information. Related Applets can be grouped into a Suite. This is often clearer and easier to maintain than placing many unrelated functions in one Applet. ### Keep pages simple Design each page around a specific step. Show users only the information and controls needed at that point in the workflow. Use: * Clear page titles. * Descriptive field labels. * Familiar terminology. * Logical field order. * Easily identified action buttons. * Confirmation and error messages where needed. Avoid overcrowding pages, especially when the Applet will run on a handheld device. ### Minimize user effort Reduce unnecessary typing, navigation, and repeated data entry. When practical: * Use barcode scanning. * Retrieve existing information from tables. * Set known values automatically. * Reuse information already held in records. * Provide sensible default values. * Move users directly to the appropriate next step. A good operational Applet should help users complete frequent tasks quickly and consistently. ### Validate before saving Use conditions to verify important information before adding or updating table data. Check that: * Required values are present. * Values use the expected format. * Quantities or other numeric values are valid. * The intended table entry was selected. * Duplicate or incomplete entries are avoided. * The operation can be completed safely. Provide a clear message when the workflow cannot continue. ### Use clear navigation Users should understand where they are, what they need to do next, and whether an operation succeeded. Provide an appropriate way to: * Continue to the next step. * Return to a previous page. * Cancel or restart the workflow. * Correct an error. * Confirm completion. Button labels should describe the action whenever possible, such as **Save Check-In** or **Return to Search**. ### Design for the deployment environment Consider where the solution will be used. A warehouse handheld, desktop Web App, and mobile phone may require different page layouts and interaction methods. Also consider: * Screen size. * Barcode-scanning requirements. * Lighting and working conditions. * Network availability. * Offline operation. * Whether users may be wearing gloves. * How frequently the workflow will be performed. Test the Applet using the same type of device and conditions expected in actual use. ### Build, test, and improve Begin with the simplest version that completes the required workflow. Test it using realistic data and representative users. Confirm that: * Records and bindings behave as intended. * Information is added or updated correctly. * Conditions handle expected exceptions. * Navigation is clear. * Offline behavior works when required. * The complete Suite works on its intended devices or as a Web App. Refine the solution based on actual use rather than attempting to anticipate every possible feature before deployment. {% hint style="success" %} A successful DC Works solution should make the user’s task faster, clearer, and more consistent while storing the required information accurately. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.amltd.com/dc-works/core-concepts/dc-works-design-best-practices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.