Appearance
Branded portals
Portals bring NOOSAdmin content and actions together for a particular audience. Each portal can have its own URL, stylesheet, branding information, menu and pages. Access can be provided to one or more user groups.
A portal can organise the parts of an application that people need for their work: information to consult, records to inspect, forms for submitting data and actions for initiating computation.
Portal identity
A portal's stylesheet and branding information allow its presentation to reflect the application or audience it serves. Its own URL provides an entry point to that experience.
The portal identity should help users recognise where they are and what the application is for. The exact styling configuration and URL arrangement belong to the implementation of the deployment.
Different portals can serve different audiences within the broader application. For example, an analytical audience and an operational audience may need different navigation and content even when they work with related data.
Menus and pages
Portals have their own menus and pages. Portal administrators can create pages that expose the relevant platform content and functionality.
A useful menu follows the tasks of its audience. An illustrative analyst portal might provide pages for inspecting measurements, initiating an analysis and reviewing results. An operational portal might centre on summaries and record exploration.
These names are examples of information organisation, not predefined NOOSAdmin navigation items. The page content should reflect the configured features and the audience's permissions.
Available page content
| Content or functionality | Purpose within a portal |
|---|---|
| Dashboard | Present queried information. |
| Explorer | Support browsing and querying records. |
| Ingress form | Provide an entry point for submitting data. |
| Ingress management information or API links | Provide relevant ingress management information or access points. |
| Runner | Expose runner-related functionality. |
| Runner trigger | Allow users to initiate a configured runner. |
These options allow a portal to combine viewing information with taking action. The detailed behaviour of each feature remains part of its own configuration. A portal page does not automatically define an ingress submission format or the inputs required by a runner.
Group access
A portal can be accessible to one or more user groups. This lets the application team select its audience through the organisation's access arrangement.
Plan portal access together with permissions on the underlying entities. An audience that can consult a dashboard may have different requirements from one that manages ingress or invokes external computation. Access to the portal should not be assumed to grant every permission needed by its content.
The access model is explained in Organisations, users and access. Portal planning applies that model to the user-facing experience.
Example: two audiences for equipment information
In an illustrative monitoring application, analysts inspect measurements and work with an external analysis model. Their portal could provide an explorer, a configured runner action and a dashboard querying stored results.
Operational users need a regular view of equipment information. Their portal could focus on summary dashboards and an explorer for the relevant records. The application team would arrange group membership and resource permissions for each audience.
The two portals can have their own navigation and branding. Their content still depends on the application's tables, queries and processing arrangements. This lets the team organise experiences around distinct responsibilities while maintaining the relationships between the underlying information.