Components
Components are the reusable pieces used to build Pianola application screens.
They include layout elements, input fields, related-record displays, action buttons, and media components. Together, they make it possible to assemble application screens that match the client's workflows without starting from scratch each time.
Components sit inside the larger application foundations described elsewhere in this documentation. Foundations define the app shell, modules, views, tabs, lists, queries, permissions, and workflow rules. Components are the smaller screen-level pieces that fill those structures: the fields users edit, the tables they scan, the buttons they click, and the layout elements that make a record view understandable.
This section explains the component catalogue at project level. It does not document code-level settings. The purpose is to make it easier to discuss what a screen should contain, how information should be arranged, and which component patterns fit the work users need to do.
How to Read This Section
Each component page explains what the component does, when it is useful, what can be configured, and which nearby components are commonly used with it.
The goal is not to turn project teams into developers. The goal is to give them enough language to recognise useful possibilities, discuss screen design, and make informed project decisions.
Layout Components
Layout components organise a screen before individual fields or tables are considered.
Rows, columns, content blocks, tab groups, modals, dividers, and spacers define how information is grouped and how much visual weight each part of the screen receives. They do not usually store data themselves. Instead, they help users understand which pieces of information belong together and where to look next.
Good layout choices are especially important on dense record views. A long flat form can make every field feel equally important, even when some information is primary and some is only occasionally needed. Rows, columns, tabs, and collapsible sections allow a screen to follow the shape of the workflow rather than the order of the database.
Input Components
Input components are the fields users use to enter or change information on a record.
Some inputs are open-ended, such as text fields, text areas, rich text, and file uploads. Others guide users toward controlled values, such as selects, radio buttons, checkboxes, checkbox groups, taggers, datepickers, timestamps, autocomplete fields, and search-or-create fields.
Choosing the right input affects data quality as well as usability. A status field may need a fixed select so reporting stays consistent. A long list of organisations may need autocomplete so users can search instead of scrolling. A simple yes-or-no value may be clearer as a switch or checkbox than as a dropdown.
Input choices should usually be made together with decisions about validation, required fields, read-only states, permissions, and conditional display. The component determines how the field appears; the surrounding application rules determine when it can be changed and what other parts of the screen depend on it.
Related-Record Components
Related-record components show records connected to the current record.
They are used when one record needs to display associated participants, tasks, documents, contacts, bookings, line items, applications, notes, or other linked information. A record data table is useful when users need structured rows and columns. Cards can be better for small sets of contact-style or summary records. A record portal can bring one related record into view without making users leave the current screen.
These components are often central to how Pianola supports real workflows, because many business processes are not about one record in isolation. A project, event, organisation, or application may need several related areas visible from the same place. The important project decision is not only which relationship exists, but how users need to review, add, edit, compare, or navigate those related records.
Action Components
Action components let users do something from the interface.
Action buttons can send emails, generate documents, update statuses, start a workflow, export information, or sync with another system. Link buttons take users to another location. PDF buttons give access to generated or stored PDF documents.
Actions should be placed where the decision to use them naturally happens. A button that approves a record, sends a reminder, or generates a document usually belongs close to the relevant status, contact details, or document area. Visibility rules and confirmations are often just as important as the button itself, especially when an action affects external recipients, external systems, or approved data.
Media Components
Media components show visual material connected to a record.
Image displays, image galleries, and video players are useful when visual reference material is part of the work. This might include profile photos, venue images, artwork, product images, instructional videos, or uploaded documentation that needs to be viewed in context.
Media components should support the task rather than dominate the screen by default. A single identifying image may sit beside key record details, while a gallery may belong in its own section when users need to browse several files. The right choice depends on how often the media is used and whether it is mainly decorative, identifying, evidential, or instructional.
Combining Components
Most useful screens combine several component types.
A participant record might use layout rows for contact and application details, input components for editable fields, a related-record table for communication history, an action button for sending a confirmation, and an image display for a profile photo. A project dashboard might combine content blocks, record data tables, links, and actions without behaving like a traditional edit form.
The component catalogue is therefore best read as a set of building blocks, not as a list of isolated widgets. The practical question is usually: what should the user understand, enter, compare, or trigger at this point in the workflow?
After that is clear, the individual component pages can help identify which pattern fits best and which configuration choices need to be discussed.