You design user interaction in an MDriven application by defining what users can do, where they can do it, and what feedback they receive in MDriven Designer and Turnkey.
User interaction is the part of the application that lets a user navigate, edit data, run an action, confirm a choice, or manipulate data directly in a view. For example, a user can select a person, change the person's name, select Save, and receive confirmation that the data was saved.
Define user actions
A user action is an operation that a user can invoke from the user interface. User actions control availability and navigation; they are distinct from general system programmability.
MDriven supports three action scopes:
| Scope | Where the user finds it | Example |
|---|---|---|
| Global action | The main menu | Open customer overview opens a customer ViewModel. |
| Class action | The left-side menu when an object of its class is available | Add order is available when the user is working with a Customer object. |
| ViewModel action | One specific view | Save changes is available only in an edit-person view. |
A ViewModel defines the data and presentation structure for a view. An action can navigate to a ViewModel. When that ViewModel needs a root object, provide the object that the view will show. For example, an action that opens an edit-profile ViewModel can use the logged-in user as its root object.
Organize global actions
Place global actions in menu groups to build the main menu hierarchy. A menu group name can include a path. For example, placing an action in Views/Submenu puts it below Views and then Submenu.
Use each action's sort order to control its position within a group. For example, an action with sort order AAA appears before an action with BBB in the same group.
Keep global navigation available when users need to move between areas of the application. If you hide both the menu bar and side bar, users cannot reach global actions unless the current ViewModel provides its own navigation actions.
Give users clear save feedback
Tell users when an operation has completed. After a user changes a value and selects Save, Turnkey can show a notification that the data was saved. This confirms that the user's changes were persisted rather than remaining only in the current editing state.
Design the save and cancel path before hiding navigation areas. For example, place Save and Cancel in a toolbar when the side bar is hidden, so both actions remain reachable.
Use modal views for focused tasks
A modal view is a view that appears over the current application and blocks interaction with the underlying view until the user completes or dismisses it.
Use a modal view for a short, focused decision or selection:
- Confirm a destructive operation, such as deleting an item.
- Collect a small set of values in a form.
- Search for and select an object without leaving the current task.
- Require authentication before allowing access to a feature.
For example, instead of navigating away from an order form to find a customer, open a customer seeker as a modal view. The user searches, selects a customer, closes the modal view, and the calling view uses the modal result to set the order's customer.
A modal view needs a clear completion rule. Define when the user is allowed to accept it, such as when a required selection exists, and define what happens after the modal view closes. Avoid using modal views for long workflows or repeated interruptions.
Support direct manipulation when it fits the task
Some interactions work best when users manipulate data in the view rather than invoke a menu action. For example, users can drag cards between lists on a Kanban board, move an SVG object with the mouse, or move a marker on a map. The interaction must update data and save it when appropriate.
Complete model examples include concrete implementations:
- An SVG example where users move graphical objects with mouse events.
- A Google Maps example where users move a marker and update its position.
- A Trello-like board where users move cards between lists.
- An interactive Gantt chart for timeline data.
Design checklist
- Give each action a specific user goal. For example, use Create customer rather than a generic action that also edits and deletes customers.
- Put application-wide navigation in global actions and view-specific operations in ViewModel actions.
- Keep save, cancel, and required navigation reachable in every view layout.
- Confirm completed saves and other state-changing operations.
- Use modal views for bounded tasks that require the user's decision before work can continue.
- Use direct manipulation only when the visible interaction clearly represents the data change.