Open Presentation Profile

1. Purpose

The Open Presentation Profile (OPP) defines a neutral, minimal, and durable UI/UX and documentation structure for open standards and open-source projects.

OPP exists to ensure that open technical work:

• Is clearly understood as free and open
• Is legible and trustworthy over long time horizons
• Avoids persuasion, marketing, and visual bias
• Remains usable decades after publication

2. Core Principles

• Neutrality: The interface MUST inform, not convince. No persuasive language or growth framing.
• Explicit Freedom: Freedom must be visible. Users must immediately understand no registration or tracking is required.
• Longevity: Layouts and links MUST be designed to remain valid and readable for 15+ years.
• Predictability: Navigation and terminology MUST be consistent.

3. Why OPP Exists

The Trust Gap Problem

Currently, open-source projects face a perception problem:

• "Ugly" sites → Users assume abandoned, unsafe, or amateur
• "Polished" sites → Users assume commercial, tracking, or hidden pricing

OPP creates a third category: "Institutional" — professional enough to trust, boring enough to believe is truly free.

What OPP Solves

The Key Innovation: Declaration Strip

This element at the top of every OPP page is the signature feature:

Open Standard · Free to Use · No Registration · No Tracking

It functions as a legal signal, trust signal, UX signal, and social contract — all in one line.

4. Specification (Normative)

4.1 Dimensions & Flow

• Width: Maximum readable content width MUST be between 720–960px.
• Alignment: Main content MUST be centered.
• Responsiveness: Layout MUST default to a single-column flow on smaller screens. Code blocks MUST support horizontal scrolling.

4.2 Mandatory Elements

Declaration Strip (Required)

Every page MUST include a visible declaration near the top:

Open Standard · Free to Use · No Registration · No Tracking

Status Indicator (Required)

Each document MUST display its status. Allowed values:

• Draft — Work in progress
• Stable — Ready for use
• Frozen — No changes expected
• Deprecated — Superseded or abandoned

Navigation Structure

Sites SHOULD use:

1. Overview — Definition and Scope
2. Specification — Canonical Truth
3. Examples — Practical Input/Output
4. Governance — Maintenance & Disputes
5. License — Legal Text

Header Purpose (The Core Rule)

Headers in standards are identifiers, not storytelling devices.

• Authority vs. Narrative: Headers MUST establish authority through clarity, not frame a narrative.
• Orientation: Headers MUST exist solely for placement and orientation within the technical ecosystem.
• Visual Restraint: OPP MUST NOT require or encourage newspaper-style headers (mastheads, slogans, or banners) for primary document identity.

4.3 Content & Tone

4.4 UX Anti-Patterns (Forbidden)

• Email capture forms
• Analytics trackers
• Cookie banners (unless legally unavoidable)
• Testimonials or partner logos
• Roadmaps framed as promises
• CTAs like "Sign up" or "Get Started"
• Newspaper-style mastheads or brand-centric banners

4.5 URL Conventions & Versioning

• URLs MUST be treated as permanent
• Each version MUST have a stable path (e.g., /v0.1/)
• Previous versions MUST NOT be overwritten
• A /latest/ pointer MAY exist but must not replace archived versions

4.6 Accessibility

• Use semantic HTML (logical h1 → h2 → h3 order)
• Support full keyboard navigation with visible focus indicators
• Provide a "Skip to Content" link
• Render core content without JavaScript
• Respect prefers-reduced-motion

5. Color Reference

These colors are chosen for WCAG AAA accessibility — ensuring readability for users with visual impairments, color blindness, and low-vision conditions.

Why WCAG AAA?

Why exceed minimum? Standards documents are read carefully for extended periods. Higher contrast reduces eye strain for everyone.

Light Mode Palette

Dark Mode Palette

Colors to Avoid

6. Typography Reference

Type Scale

Why 17px Body Text?

• 16px is browser default; 17px provides slight improvement
• Larger text reduces eye strain on long documents
• Better readability on mobile devices
• Accommodates users who don't adjust browser zoom

Why 1.6 Line Height?

• WCAG recommends at least 1.5 for body text
• 1.6 provides comfortable spacing for extended reading
• Helps dyslexic users track lines more easily

Font Stack

--font-body: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;
--font-mono: SFMono-Regular, Consolas, "Liberation Mono", Menlo, monospace;

Why System Fonts?

• Zero load time — No external font requests
• Familiarity — Users see their OS's native font
• Neutrality — No brand association
• Accessibility — System fonts are optimized for on-screen reading
• Longevity — No dependency on external CDN availability

7. Interactive Pages (Playgrounds)

OPP-compliant sites MAY include interactive pages such as playgrounds, sandboxes, or visual explorers. These pages are considered non-normative and MUST NOT be required to understand, implement, or validate the standard.

7.1 Playground Requirements

If a playground is provided, the following rules apply:

• Playgrounds MUST be clearly labeled as Non-Normative
• Playgrounds MUST NOT replace written examples
• Playgrounds MUST NOT contain authoritative behavior definitions
• All normative rules MUST remain accessible without JavaScript

7.2 JavaScript Usage

• JavaScript MAY be used in playground pages
• JavaScript MUST NOT be required to access:
  • Specifications
  • Rules
  • Definitions
  • Governance
  • License text
• If JavaScript fails or is disabled, the core documentation MUST remain fully readable

7.3 Placement & Navigation

• Playground pages SHOULD be separated from core documentation
• Recommended paths: /playground, /tools, or /sandbox
• Playgrounds MUST NOT be the default landing page
• Navigation to playgrounds MUST NOT be visually emphasized over documentation

This prevents the site from becoming "product-like".

Why This Matters

Many open standards fail UX-wise because:

• Everything is static → feels dead
• Or everything is interactive → feels untrustworthy

OPP allows interaction without corruption. Playgrounds are tools, not truth.

8. Implementation Guidelines

For Authors

• Use strictly hierarchical headers. Never skip levels for visual effect.
• Separate normative rules (MUST) from informative context (Note:).
• Use tables for data comparison; avoid complex nested lists.
• Always specify language tags in code blocks.

For UI/UX Designers

• Role: You are a steward of clarity, not a creator of "experience."
• Goal: The user should feel safe, not excited.
• Constraint: If a design element requires explanation, remove it.
• Success: The site looks 10 years old (in durability) and 1 minute old (in freshness).

For Developers

• No-JS First: The site MUST be fully readable with JavaScript disabled. JS MAY be used for enhancement only.
• Dependencies: Zero or minimal build steps preferred.
• Performance: Use system fonts to prevent FOUT and layout shifts.
• URLs: Treat every URL as permanent. Never break links.

Animation Rules

• Animation is discouraged
• If used, MUST be subtle and non-informational
• Scroll-based storytelling is PROHIBITED
• Full-screen transitions are PROHIBITED
• MUST respect prefers-reduced-motion

9. Compliance Checklist

Use this checklist to verify OPP compliance before publishing.

Verification Tool: WebAIM Contrast Checker

10. Logo & Branding

The OPP logo is a circle containing three horizontal lines of decreasing length—representing structured text/profile within an open, accessible container.

Design Symbolism

• Circle: Openness, completeness, accessibility
• Lines: Structured content, hierarchy, readability
• Decreasing length: Information hierarchy, progressive disclosure

Usage Rules

Specifications

Favicon Data URI

<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><circle cx='50' cy='50' r='44' fill='none' stroke='%23111' stroke-width='6'/><line x1='24' y1='35' x2='76' y2='35' stroke='%23111' stroke-width='6'/><line x1='24' y1='50' x2='68' y2='50' stroke='%23111' stroke-width='5'/><line x1='24' y1='65' x2='56' y2='65' stroke='%23111' stroke-width='5'/></svg>">

11. License Reference

The Open Presentation Profile (OPP) is licensed under CC BY 4.0.

You are free to share and adapt this material for any purpose, even commercially, provided you give appropriate credit.

View full license text →

Recommended Licenses for Documentation

For standards, specifications, and prose content:

Recommended Licenses for Code

For software, reference implementations, and tools:

Dual Licensing Pattern

Many projects use dual licensing:

Documentation: CC BY 4.0
Code: MIT License

Compliance Declaration

Projects MAY declare:

"This site follows the Open Presentation Profile (OPP)."

Compliance is voluntary and self-declared. No certification authority is required.

12. Status Colors

A calm, standards-grade color set for status badges. Timeless, accessible, non-flashy.

No gradients. No neon. No "startup energy".

Usage Rules

• Status colors are informative only — MUST NOT imply priority or popularity
• Color + text always together (never color alone)
• Small badges, uppercase or title case
• No animation, no icons required

Badge Examples

Accessibility

• All colors pass WCAG AA contrast on white backgrounds
• Work equally well inverted on dark backgrounds
• Color-blind friendly (paired with text labels)
• Print-friendly hex values

13. Version & Release Standard

Mandatory Metadata Block

Every OPP-compliant page MUST expose a Metadata Block near the top, visible without scrolling.

Version Format

OPP RECOMMENDS Semantic Versioning:

MAJOR.MINOR.PATCH

Examples: v1.0.0, v0.3.2

• Version MUST be explicit
• Version MUST NOT be implied by URL alone
• Version MUST NOT be replaced retroactively

Release Date Format

Time is part of trust.

YYYY-MM-DD
YYYY-MM-DDTHH:MM:SSZ

• MUST be UTC
• MUST NOT use relative language ("last week")
• MUST NOT be omitted for Stable/Frozen releases

Status–Version Compatibility

Visual Layout

Option A — Single line:

Status: Stable · Version: v1.0.0 · Released: 2026-01-27

Option B — Stacked:

[ STABLE ]
Version: v1.0.0
Released: 2026-01-27

Time Semantics

Example (Canonical)

Status: Stable
Version: v1.0.0
Released: 2026-01-27
Last updated: 2026-02-10

This is citation-safe, audit-safe, and future-proof.

14. Search & Social Metadata (Non-Normative)

OPP-compliant sites MAY include minimal metadata to support search indexing and neutral link previews.

14.1 Search Engine Metadata

If provided, the following rules apply:

• Page titles MUST reflect the actual document or standard title.
• Meta descriptions MUST be factual, neutral, and descriptive.
• Keywords, ranking tactics, or growth-oriented metadata SHOULD NOT be used.
• Canonical URLs SHOULD be declared for versioned documents.

<title>OPP v0.1</title>
<meta name="description" 
      content="A neutral profile for open standards.">

<meta name="description" 
      content="The best standard you should use today.">

14.2 Social Link Previews

OPP-compliant sites MAY include Open Graph or similar metadata.

• Titles/Descriptions MUST match document content.
• Preview images MUST be neutral (logo or text only).
• No emojis, slogans, or CTAs.

14.3 Prohibited Practices

• SEO manipulation techniques
• Optimizing for click-through rates
• Social share prompts
• Tracking pixels or analytics

User-agent: *
Allow: /

# Normative documentation MUST remain accessible.
# Non-essential paths MAY be restricted if needed.

Sitemap: https://example.org/sitemap.xml

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.org/</loc>
    <lastmod>2026-01-27</lastmod>
  </url>
  <url>
    <loc>https://example.org/v1.0/</loc>
    <lastmod>2026-01-27</lastmod>
  </url>
</urlset>

# llms.txt — Example Standard
# Advisory guidance for Large Language Models (LLMs)

This site publishes open standards and open protocols.

Usage:
- Content may be read, summarized, and referenced.
- Implementations should rely on the canonical specification text.
- Versioned URLs represent authoritative snapshots.

Licensing:
- Usage rights are defined by each document’s license.
- This file does not modify or override licensing terms.

Notes:
- Playground and tool pages are non-normative.
- Metadata badges indicate status, version, and release date.

16. Header & Footer Semantics

OPP-compliant sites MUST use headers and footers to provide orientation and trust — not navigation complexity or promotion.

16.1 Header

The header MUST:

• Identify the document or standard clearly
• Provide access to primary sections (e.g. Overview, Specification, Governance)
• Display status, version, and release metadata visibly

The header MUST NOT:

• Contain marketing language
• Include calls to action
• Include tracking, analytics, or social sharing controls

16.2 Footer

The footer SHOULD:

• Reference governance or stewardship
• Reference licensing information
• Provide links to source repositories (if applicable)
• Reference OPP compliance (optional)

The footer MUST NOT:

• Include promotional content
• Include newsletters, subscriptions, or metrics
• Override or restate normative content

17. Authorship & Attribution

OPP-compliant documents MAY identify authors or contributors.

Authorship exists for attribution, not authority.

17.1 Rules for Author Attribution

If authors are listed:

• Author names MUST NOT replace or overshadow the standard name
• Author identity MUST NOT be presented as endorsement or authority
• Organizational stewardship SHOULD be stated separately from authorship

17.2 Recommended Placement

Authorship SHOULD:

• Appear near the end of the document
• Or appear in a dedicated "Contributors" section
• Or be included in metadata (not the header)

Authorship SHOULD NOT:

• Appear in the hero section
• Appear above the specification
• Be used as a credibility signal

18. Legal & Privacy Notice

OPP-compliant sites are informational in nature.

If a site:

• Does not collect personal data
• Does not require registration
• Does not provide interactive services

Then a license declaration and openness statement are sufficient. Privacy policies and terms of service are unnecessary unless user data collection or contractual services are introduced.

18.1 Factual Privacy Notices

If a project requires a privacy page, the only acceptable form is a factual notice:

## Privacy

This site does not collect personal data.
No cookies, analytics, or tracking mechanisms are used.

18.2 Prohibited Legal Language

OPP-compliant sites MUST NOT include:

• "By using this site you agree..." boilerplate
• Liability disclaimers for non-commercial informational content
• Governing law or arbitration clauses

19. Temporary Placeholder Pages

OPP-compliant sites SHOULD avoid "Under Construction" pages.

Placeholder pages signal instability, break citation, and feel unprofessional in standards contexts. However, if a placeholder page is necessary, the following rules apply.

19.1 Placeholder Requirements

If a placeholder is used:

• The page MUST clearly state what is incomplete
• The page MUST indicate the expected scope (not timeline)
• The page MUST NOT contain marketing language
• The page MUST NOT block access to other published content
• The page MUST NOT request contact, signup, or notification

19.2 Acceptable vs Unacceptable Placeholders

19.3 Prohibited Patterns

OPP-compliant placeholders MUST NOT:

• Use hype language ("Coming soon!", "Stay tuned!")
• Include countdown timers
• Request email signup for updates
• Provide estimated dates
• Link to social media for announcements

20. Communication & Contact

OPP-compliant sites MUST NOT require direct contact to access, use, or understand a standard.

Contact pages imply support obligations and create authority confusion. Standards are not services.

20.1 Contact Principles

If a communication method is provided, it MUST:

• Be informational, not transactional
• Clearly state its purpose (e.g., governance, issues)
• Avoid implying support or response guarantees

20.2 Allowed vs Prohibited Contact

20.3 Recommended Alternatives

Instead of /contact, prefer:

• /governance
• /stewardship
• /issues
• /contributing

This keeps the site institutional, not commercial.

20.4 Minimal Contact Reference

If contact information must appear, it SHOULD be:

• One line only
• Placed in the footer or governance section
• Scoped to governance matters only

21. Typography

OPP-compliant sites SHOULD prioritize readability, language coverage, and long-term availability.

21.1 Technical Requirements

• System Fonts Preferred: System font stacks SHOULD be preferred where possible to ensure zero-tracking and zero-latency.
• Neutrality: Fonts MUST be neutral and non-decorative.
• Language Coverage: Fonts MUST support the languages used by the document.
• External Loading: External font loading SHOULD be avoided.

21.2 Use of Noto

Widely available fonts such as Noto MAY be used, particularly for multilingual or non-Latin content (e.g., mixing English and Arabic).

If Noto or other non-system fonts are used:

• They SHOULD be self-hosted
• They MUST NOT require third-party requests (e.g., Google Fonts API)
• Core content MUST remain readable if the font fails to load (proper fallbacks)

22. Optional Reading Modes

OPP-compliant sites MAY offer alternative reading modes optimized for long-form text consumption.

One such mode is an Editorial (Newspaper) Reading Mode.

22.1 Editorial (Newspaper) Reading Mode

If provided, an editorial reading mode MUST follow these principles:

• Focus on readability and information density
• Use typography as the primary hierarchy mechanism
• Avoid decorative or nostalgic visual effects
• Preserve all OPP accessibility and contrast requirements

22.2 Editorial Metadata Header (Optional)

In Editorial Reading Mode, a minimal metadata header MAY be used.

If present, it MUST:

• Contain only factual metadata (title, status, version, date)
• Avoid slogans, taglines, or descriptive phrases
• Avoid decorative rules, textures, or imagery
• Not replace the primary document title

22.3 Layout Rules

• Content MAY be presented in one or two columns on wide screens
• On small screens, layout MUST collapse to a single column
• Column gaps MUST be generous to avoid visual fatigue
• Sidebars MAY be used for metadata, not core content

22.4 Typography Rules

• Serif fonts MAY be used for body text
• Sans-serif fonts SHOULD be used for headings and metadata
• Line length MUST remain within readable bounds
• Line height SHOULD be increased to support dense text

22.5 Visual Style Rules

23. Notes, Quotes & Callouts

OPP-compliant documents MAY use callouts to clarify or contextualize information. Callouts exist to improve comprehension, not emphasis or persuasion.

23.1 Callout Types

• Note — additional context or clarification
• Warning — risk, constraint, or non-obvious limitation
• Example — illustrative, non-normative content
• Quote — external or contextual reference

23.2 Visual Constraints

• MUST be visually distinguishable from body text
• MUST NOT rely on color alone to convey meaning
• Text size MUST NOT be smaller than body text

23.3 Text Size

OPP-compliant sites MUST use a readable base text size.

• Body text SHOULD be at least 16px equivalent
• Headings MUST be visually distinct from body text
• Callouts MUST NOT be smaller than body text

23.4 Quotes

Quotes MAY be used for attribution or context.

• Quotes MUST be clearly attributed
• Quotes MUST NOT replace normative content
• Quotes MUST NOT be used as authority or endorsement

23.5 Color Usage

Color MAY be used to support differentiation.

Color MUST NOT:

• Be the sole carrier of meaning
• Convey urgency, endorsement, or promotion
• Reduce readability or contrast

24. Examples, Code & Tooling

Example code and tools are non-normative by definition.

24.1 Rules

• Example code MUST be clearly labeled as non-normative
• Tools MUST be optional and not required for compliance
• Tools MUST NOT redefine or extend the specification
• Tools MUST be visually separated from normative text

25. Media & Attachments

All media is non-normative. Text is authoritative.

25.1 Presentation Rules

26. Tables

OPP-compliant sites MAY use tables to present structured information.

Tables exist to organize data, not to persuade or rank.

26.1 Table Purpose

26.2 Table Content Rules

26.3 Table Accessibility

• Use semantic HTML (<table>, <th>, <td>)
• Include proper headers
• Remain readable when linearized
• Work with screen readers

27. Links & Interaction

27.1 Links

Links indicate navigation or reference, not action.

• Links MUST NOT rely on color alone
• Links MUST NOT be styled as buttons in content
• Link symbols (arrows) SHOULD be decorative and optional

27.2 Colored Identifiers

Primary colors MAY be used for decorative elements (headings), provided they do not convey meaning or status.

Appendix A: IDEL Rules Profile (Non-Normative)

This section describes an optional IDEL-based representation of OPP rules for automated execution.

OPP compliance does not require IDEL.

Appendix B: OEC Execution Contract (Non-Normative)

Defines the execution contract for create.opp.site.

# Check OPP site and read it carefully to apply everything right
# https://opp.openat.nextera.one/
instruction = "check.read.carefully"
create.opp.site
  title = "Open Presentation Profile (OPP)"
  type  = "open-standard"
  status = "draft"

Text overrides code, always.