You can use UI First in MDriven Designer to sketch a ViewModel from a proposed screen, then create the classes, attributes, and associations the screen needs while you refine the prototype.
MDriven supports two complementary ways of designing an application:
- Information first: define the business information model before designing the user interface.
- UI First: start with a screen you need to discuss or prototype, then use that screen to identify and create the required model information.
Both approaches produce a ViewModel: a declarative definition of what information is shown, how it is transformed, and the UI hints used to render it. UI First does not replace information design. It gives you a practical way to begin when the clearest requirement is a user-facing screen.
Choose a starting point
| Start with | Use it when | Example |
|---|---|---|
| Information first | You already understand the business information and its relationships. | Define Invoice, InvoiceRow, and their relationship, then create an invoice ViewModel. |
| UI First | Stakeholders describe what they need to see or do before the underlying model is known. | Sketch an invoice screen with a number, a list of rows, and an Add Row button; create the missing model elements from the screen. |
Information design remains the basis for understanding a business. Follow the information to determine what the business creates and changes. UI First helps you capture and validate that understanding early when a screen is the best starting point for the conversation.
Build a ViewModel from a proposed UI
Use the UI First tools in the ViewModel Editor when you want to turn a screen idea into a working prototype.
- In MDriven Designer, create a new ViewModel with the Target button.
- Give the ViewModel a name and select its root class (also called its type).
- If the needed class does not yet exist, create it from the Target dialog. For example, create an Invoice class for an invoice view.
- Use the UI First tools in the ViewModel Editor to place widgets in the ViewModel layout. Select a tool and drag it into the layout.
- Select a widget's Target button to define what the widget represents.
- Choose an existing expression, or create the missing model element from the Target dialog.
- Save and run the prototype. Use the result to review the screen and continue refining both the ViewModel and the information model.
A ViewModel has a context: the object type from which its expressions are evaluated. When a ViewModel is rooted in Invoice, root-level expressions use that Invoice object as self.
Example: sketch an invoice screen
Assume a stakeholder asks for an invoice screen with an invoice number, a list of invoice rows, and a way to add rows. You can begin with the screen even if the model is still empty.
Add the invoice number
- Create an Invoice ViewModel whose type is Invoice.
- Place a field where the invoice number should appear.
- Select the field's Target button.
- If Invoice has no attributes yet, create an attribute named Number from the dialog.
- Select the suggested expression
self.Number. - Accept or adjust the suggested field name, for example Number.
The field is now tied to information in the model rather than being only a drawing. The expression result type tells the ViewModel how the value can be rendered.
Add the invoice-row list
- Place a grid in the invoice layout.
- Select the grid's Target button.
- Set the grid item type to InvoiceRow. If that class is missing, create it.
- Select the collection that supplies the rows.
- If Invoice and InvoiceRow are not associated, create a new association from Invoice to InvoiceRow, with the many end named Rows.
The grid can now use the Invoice's rows rather than all InvoiceRow instances. This distinction is important: a screen for one invoice should show that invoice's rows.
Add an action area
Place a button where the user should add an invoice row, then use its Target settings to define the required action. Actions change information; read-only expressions only retrieve or calculate information. Keep the action focused on the current context—for example, adding a row to the current Invoice's Rows collection.
Work iteratively
UI First is intended for short feedback cycles:
- Sketch the screen needed for the current discussion.
- Bind each widget to existing information or create the missing information it exposes.
- Run the prototype and review it with users.
- Correct the layout, expressions, and model relationships based on what you learn.
This makes every increment testable in the prototype. As requirements change, update the ViewModel and the information model together rather than treating the UI as a separate, fixed layer.
Continue using existing ViewModel design options
UI First adds another entry point to the ViewModel Editor; it does not remove the existing information-first design workflow. You can still start from model classes and associations, add expressions to a ViewModel, and use the resulting type information and UI hints to derive the interface.
You can also use generated forms as a starting point. When you adopt an autoform into a ViewModel, you can continue editing its layout and expressions as a manually designed ViewModel. Preserve intentional changes by adopting the autoform or by creating a ViewModel from scratch; manually changed autoforms can be replaced when autoforms are recreated.
What UI First does not change
- UI First does not eliminate the need for a coherent information model. Classes, attributes, and associations created from the UI must still represent the business correctly.
- UI First does not restrict information-first design. You can move between the two approaches within the same model.
- A widget needs a valid expression or action definition before it can represent live model behavior. A layout alone is not a working ViewModel.
- ViewModel UI hints describe the intended interface. Client-side use of ViewModel metadata is covered separately in Documentation:Getting safe–limited–meta information from a Turnkey app.