UXfc — functional and intentional components

Documentation status: reference — see Maturity and evidence.

UXfc describes an interface by what the user is trying to accomplish and by the interaction functions required for that activity, before selecting widgets or a rendering technology.

Design chain

user activity
  -> usage intention
  -> functional constraints
  -> intentional UXfc component
  -> functional component
  -> registered implementation
  -> rendered interface

This separation keeps an intention stable while allowing the renderer to change.

Two levels

Intentional components

They describe the why of the interaction: exploration, selection, consultation, editing, validation, navigation, or sequencing.

Functional components

They describe the required interaction role: field, list, tabular view, button, split view, tabbed view, status view, document viewer, reactive region, and so on.

A functional component remains declarative. It may carry non-visual parameters such as data source, selection mode, navigation policy, validation, context persistence, or event contracts.

Concrete implementation

The model must not name a native UI class as a public contract. A registration table or equivalent mechanism maps the functional component to a concrete implementation for the selected target.

functional component: tabular view
        -> Web renderer implementation
        -> Desktop renderer implementation
        -> future renderer implementation

Events

Components may emit semantic events. The page controller coordinates local events and decides whether an intention remains inside the view or must be escalated to an action, process, or service.

Catalog

• Intentional components
• Basic/ — simple editing and selection functions
• Standard/ — navigation, visualization, and composition functions

Individual component pages are public only when they describe a verified portable contract. Historical implementation-dependent notes remain private.