Responsive Forms vs. Aras Classic Forms

Prior to Aras Innovator 30, there was a single way to define a Form for the Aras Innovator client, now called Classic Forms. This section outlines key differences between Responsive Forms and Classic Forms.

When defining a Classic Form, an administrator creates a new Form item and uses the Classic Form Editor UI to place fields into the Form body. The admin then drags each field to its desired position in the Form. This approach assigns each field an X,Y coordinate that the Aras Innovator platform uses to render a static layout for the Form.

Responsive Forms use an enhanced admin user interface called the Responsive Form Designer. This UI enables admins to define a container-based layout by dragging and dropping structural elements and fields into the Form. Administrators can also configure the layout behavior of the Form and preview how it will look and behave for end users.

Classic Forms render content using a static layout that doesn’t change based on the size of the user’s browser window. Instead, users will be presented with scroll bars when a Classic Form’s static content does not fit in frame, or they will see additional whitespace when the static content occupies less space than the current frame.

Responsive Forms use a container-based approach to define the layout of a Form. This means that content can reflow to use the browser window’s space more effectively – minimizing the need for scroll bars and reducing unnecessary whitespace.

Both Classic and Responsive Forms use the Form ItemType to define Forms for the Aras Innovator client. However, each approach uses a different data structure under the Form item to describe the layout, behavior, and content of the rendered Form.

This parallel architecture enables administrators to adopt Responsive Forms with minimal disruption to packaging and deployment. It also enables customers to continue using their existing Classic Forms.