F34.us Content Aggregator Prototype

How a Portfolio Composes Itself

The design and architecture behind F34's tile providers, layout engine, privacy boundary, and graceful fallbacks.

F34's project panels are built from candidates rather than hard-coded slots. Each showcase provider examines a project and offers useful blocks for the content it understands: images, videos, articles, files, development activity, or connected services. Providers supply priorities, preferred spans, categories, timestamps, and presentation templates, while the project page remains unaware of their internal details.

The layout engine turns those candidates into a composition for the current surface. It gives special consideration to featured artifacts, then seeks a useful balance of visual material, activity, and integration context. Candidates are deduplicated and expanded toward their preferred grid spans, allowing one image to occupy a dominant region while denser informational blocks remain compact. The same vocabulary can serve a portfolio panel, a project list, or a more expansive project dossier.

Resilience is part of the design. A failing provider is isolated so the rest of the showcase can still render, and a deliberate overview becomes the fallback when no richer content is available. Connected services do not make live requests during page rendering; they contribute bounded cached summaries and activity instead. That keeps a public portfolio fast and understandable even when an upstream service is unavailable.

Editorial control and automatic composition are intentionally separate. The owner decides which projects are public, which work is featured, and what claims to make about role or impact. The provider system supplies evidence from content that already passes the page's visibility rules. This lets the portfolio feel alive without allowing an integration to write its marketing story—or expose a private one.

F34.us Background Image