Design for Post Page

Design for a post page like https://datahub.io/core/finance-vix

We'll likely have at least 3 types:

Below is a concise, structured set of job stories, written to be design-guiding rather than prescriptive. It separates who from what the page must enable

assets/datahub-core-finance-20251231173011 Current state of page as of 2025-12-31 (needing some love)

Users

  1. General data analyst / data-curious reader
  2. Data engineer / advanced practitioner
  3. Data publisher / author (secondary, but relevant)

User behavior insights

  • Most users decide whether to stay within ~10 seconds; orientation must be immediate (Nielsen 2006).
  • Non-engineer analysts engage more with examples and visuals than with specifications (Few 2012).
  • Trust increases when provenance and update signals are visible but unobtrusive (Norman 2013).
  • Heavy metadata early reduces engagement for exploratory users (Cairo 2016).

Page design (summary)

  • 🔥 The page is designed as a data publication, not a catalog.
  • The top of the page is system-shaped to orient and demonstrate value quickly, while the main body remains author-controlled, blog-like, and expressive.
  • The reading flow is story → insight → use → extraction, with technical detail deferred until explicitly sought.

Structural design

Very crude page sketch (ASCII)

┌──────────────────────────────────────────────┐
│ HEADLINE                                     │
│ Short narrative lead (what + why + use)      │
│                                              │
│ [ Primary Chart or Table ]                   │
│ Key takeaway caption                         │
└──────────────────────────────────────────────┘

┌───────────────┬──────────────────────────────┐
│ (optional)    │                              │
│ TOC           │   Main data post body        │
│               │   - narrative                │
│               │   - charts                   │
│               │   - tables                   │
│               │   - explanations             │
│               │                              │
│               │                              │
└───────────────┴──────────────────────────────┘
                        │
                        ▼
            ┌──────────────────────────┐
            │ Data files / downloads    │
            │ Previews / assets         │
            │ License / updates         │
            └──────────────────────────┘

  • The top section (system-owned) establishes orientation and value:

    • Headline + short narrative lead
    • One decisive chart or table (fallback-safe)
    • Minimal trust cues (recency, curator)

  • The main body (author-owned) is a free-form data post:

    • Narrative, charts, tables, explanations
    • No strict enforcement; style is encouraged, not imposed

  • System affordances (files, downloads, metadata) are visually secondary and do not interrupt the reading flow.

This mirrors successful data journalism patterns rather than reference systems (Cairo 2016; Nielsen 2006).

Stylistic features

  • Narrative-first, chart-oriented
  • Plain language over technical jargon
  • Progressive disclosure of complexity
  • “How to use” emphasized over “what fields exist”
  • Metadata hidden unless it affects interpretation or reuse

Explicitly not a schema browser or dataset registry.

Control boundaries

  • Controlled by system:

    • Above-the-fold structure
    • Placement of primary visual
    • Presence (not ordering) of data files and assets

  • Controlled by author:

    • Main narrative content
    • Choice and sequencing of visuals
    • Depth of explanation

This preserves editorial freedom while ensuring consistent orientation.

Job stories

Orientation and sense-making (primary)

  • When I land on a data post or dataset page, I want to quickly understand what this data is about and why it matters, so that I can decide whether to keep reading or move on.

  • When I see a chart or table at the top of the page, I want it to immediately communicate a meaningful pattern or insight, so that I grasp the value of the dataset without digging.

Exploration and interpretation

  • When I scroll the page, I want to see key insights, patterns, or examples of analysis, so that I can understand what questions this data can help answer.

  • When visuals are present, I want short explanations of what to notice, so that I don’t misinterpret the data.

  • When no visuals are present, I want a compact tabular preview or summary, so that I can still assess usefulness.

Evaluation for use (analyst-oriented)

  • When I am considering using this dataset, I want to understand typical use cases and limitations, so that I can judge whether it fits my analytical needs.

  • When I am interested in reuse, I want to know roughly what the data covers (time span, geography, granularity), so that I can assess compatibility with my work.

Access and extraction

  • When I decide the data is useful, I want to easily download the dataset files, so that I can start working with them immediately.

  • When I see a chart or table, I may want to download it as an image or extract the underlying data, so that I can reuse it in my own analysis or presentation.

Deeper technical inspection (engineer-oriented, secondary)

  • When I need more technical detail, I want access to schema, formats, update cadence, and provenance, so that I can integrate the data reliably into pipelines.

  • When the data is updated over time, I want to see versioning or a changelog, so that I can track changes and avoid silent breakage.

Trust and credibility

  • When I encounter unfamiliar data, I want to know who published it and where it comes from, so that I can assess credibility.

  • When I rely on this data, I want clear licensing information, so that I know how I am allowed to use it.

Discovery and continuation

  • When I find a useful dataset or post, I want to easily discover related data stories or datasets, so that I can continue exploring the topic.

  • When I like this kind of data, I want to follow or subscribe, so that I see future updates without having to search again.

Notes for later design (non-binding)

  • Most users will satisfy or abandon their job by the end of the orientation + exploration phases.
  • Technical completeness matters, but only after value is demonstrated.
  • Dataset pages differ from blog posts mainly in the presence of system-owned objects (files, previews, assets), not in narrative intent.

If this looks right, the next step is to cluster these job stories into page regions (top, body, sidebar, footer) and identify which jobs are system-owned vs author-owned; that is where design decisions properly begin.