HIFDocs
HIF / Documentation / Adaptation

HIF Application Profiles

1. Purpose of profiles

A profile refines HIF for a particular class of interface. A single product MAY use multiple profiles.

Example:

OS installer
= application profile
+ builder/safety profile
+ documentation profile

A profile defines additional requirements but does not override the Constitution.

2. OS Shell Profile

Applies to the desktop shell, panel, launcher, workspaces, windows, system settings and notifications.

Required properties

  • applications, processes, windows, task representations and shortcuts are clearly distinguished;
  • launching and termination follow a coherent model;
  • the launcher, running tasks and system controls are accessible by keyboard;
  • a lost or inaccessible window can be recovered;
  • focus moves predictably between windows and overlays;
  • accessibility settings are available before authentication, where applicable;
  • session, sign-out, restart and shutdown flows are secure;
  • the shell continues to work when optional network services fail;
  • system alerts can take precedence over application chrome without overusing modal interruption.

Permitted variation

  • floating, tiling, stacking or full-surface windows;
  • a panel, dock, overview or command-first navigation;
  • single or double activation;
  • icon, label or managed-list task presentation;
  • desktop items or no desktop items;
  • different density and motion profiles.

Invariants

A change of environment does not alter object identity, authority, command effects or accessibility semantics.

3. Desktop Application Profile

Applies to productivity-oriented native and web-desktop applications.

Required properties

  • document and project states are distinguishable;
  • unsaved changes are protected;
  • open, save, export and publish have distinct names and effects;
  • menus and shortcuts follow platform conventions;
  • long-running work does not block the entire application unnecessarily;
  • undo and redo are defined by the domain model;
  • multi-window and multi-document behaviour is documented;
  • errors do not destroy valid work.

A professional application SHOULD support accelerators and a high-density mode without reducing baseline accessibility.

4. Web Product Profile

Applies to websites, portals, SaaS products and web applications.

Required properties

  • semantic HTML is the default;
  • each page has a meaningful title and landmarks;
  • the URL represents significant navigational state;
  • browser history and the Back command continue to work;
  • a deep link opens in a meaningful context;
  • responsive and reflow behaviour is defined;
  • essential information does not depend on hover;
  • loading, offline and network-error states are represented;
  • authentication and consent do not employ dark patterns;
  • WCAG 2.2 Level AA is the baseline target.

Single-page application behaviour should not violate established web conventions without necessity.

5. Documentation Profile

Applies to reference material, guides, knowledge bases and policy documents.

Required properties

  • a durable information architecture;
  • a content-first layout;
  • explicit navigation and a clear current location;
  • deep links to sections;
  • readable typography;
  • code blocks that support copying without preventing manual selection;
  • the version and status of every normative document;
  • search where the volume of material makes manual navigation ineffective;
  • accessibility without client-side JavaScript where practicable;
  • a clear distinction between tutorials, how-to guides, reference material and explanation.

Documentation should not resemble a marketing landing page when its primary purpose is reading and retrieval.

6. Builder and Administrative Profile

Applies to operating-system builders, release management, registries, billing, identity systems and control planes.

Enhanced requirements

  • the object, environment and tenant are always distinguishable;
  • a destructive action identifies its exact scope;
  • draft, queued, running, built, tested, signed, published, revoked and failed are distinct states;
  • approval and execution are separated for high-risk actions;
  • an audit trail is available;
  • permissions are visible before an action;
  • secret values are not disclosed through the interface, logs or clipboard;
  • a bulk operation provides a preview and a partial-result model;
  • retrying does not duplicate a consequential operation;
  • an irreversible operation requires enhanced verification;
  • a background job preserves its status after the user leaves the page.

7. Installer and Recovery Profile

Required properties

  • the target disk or device is shown unambiguously;
  • destructive partitioning is separated from navigation;
  • a summary is presented before changes are applied;
  • the risk of data loss is described specifically;
  • progress is not simulated;
  • the consequences of interruption are explained;
  • logs and a recovery path are available;
  • keyboard access and accessibility are maintained until installation is complete;
  • offline documentation is available where network access is not guaranteed.

A confirmation such as “Are you sure?” is insufficient unless it identifies the target.

8. Kiosk and Distance Profile

Required properties

  • targets and text are sized for the expected viewing and operating distance;
  • navigation depth is minimised;
  • recovery after inactivity is clear;
  • there are no dead ends;
  • network and service status is understandable;
  • session data is cleared in a privacy-preserving manner;
  • the inactivity timeout is safe;
  • the input model corresponds to the hardware;
  • critical functionality is available without fine motor control.

A kiosk MAY restrict freedom of navigation, but MUST show the available actions clearly.

9. Retro and Historical Profile

Purpose

Convey the structure and character of a historical graphical interface without reproducing its barriers.

Permitted

  • characteristic composition;
  • pixel typography;
  • hard borders;
  • a limited palette;
  • historical activation conventions;
  • low-resolution geometry where appropriate.

Not permitted

  • unreadable mandatory text;
  • very small hit areas without an alternative;
  • functionality available only through double-clicking or dragging;
  • absence of visible focus;
  • unauthorised copying of proprietary assets;
  • presenting a stylistic interpretation as the original system.

A readability floor and accessibility override apply.

10. Terminal and Command Profile

Required properties

  • commands, arguments and quoting are distinguishable;
  • copying and pasting work unless there is a sound reason otherwise;
  • a destructive command identifies its target clearly;
  • progress and exit status are available;
  • structured output is available to automation;
  • errors include actionable context;
  • history does not retain secrets;
  • terminal colour is not the sole information channel;
  • screen-reader workflows are taken into account.

The GUI and CLI SHOULD use a common domain command model where possible.

11. Conversational and AI Profile

Required properties

  • the agent's identity and capabilities are clear;
  • suggestions, drafts, plans, commands and results are distinguishable;
  • tool use and permissions are observable;
  • a high-risk action has a preview and an approval step;
  • sources and uncertainty are shown in proportion to risk;
  • a person can edit the plan;
  • execution can be stopped when it is safe to do so;
  • the history makes changes understandable;
  • a result does not conceal failure or partial completion;
  • conversational output has an alternative structured representation for complex data.

An anthropomorphic form should not create a false impression of the system's knowledge, intentions or responsibilities.

12. White-label Profile

A white-label implementation MAY change:

  • the name;
  • the logo;
  • the palette;
  • the typography;
  • the iconography;
  • the domain;
  • the content tone;
  • the default configuration.

A white-label implementation MUST NOT change:

  • the accessibility floor;
  • semantics;
  • security warnings;
  • legal identity where it is required;
  • provenance;
  • consent;
  • command effects;
  • truthful information about updates and support.

A BrandPack is data and tokens layered over the product, not a fork of its behaviour.

13. Immersive and Spatial Profile

Applies to augmented-reality, virtual-reality and spatial interfaces.

The profile additionally defines:

  • the physical safety boundary;
  • locomotion alternatives;
  • seated and standing use;
  • reduction of motion sickness;
  • alternatives to spatial audio;
  • reachable zones;
  • privacy for gaze and gesture data;
  • recentring and escape;
  • a fallback two-dimensional representation for essential tasks.

Immersion does not justify the absence of a system exit or loss of control.

14. Creating a new profile

A new profile should describe:

  1. its context;
  2. its users and tasks;
  3. its distinctive risks;
  4. additional MUST requirements;
  5. permitted variation;
  6. unacceptable compromises;
  7. validation tasks;
  8. its relationship to existing profiles.