Card Commons specification · v0.1

UX and interaction specification

Information architecture, editor behavior, public views, mobile, and accessibility.

All specifications

UX and interaction specification

Experience principle

The user is always editing a card inside a larger card system, never an unbounded canvas. Every important view keeps structured meaning and visual appearance legible together.

MVP information architecture

The signed-in product has four primary destinations:

  • Studio: create and edit individual cards.
  • Stacks: arrange stacks, decks, and series.
  • Games: build and play prompt-response games.
  • Publish: review public objects, URLs, and exports.

Assets and account settings are secondary destinations. Ontology and system editing remain future modules.

The dashboard shows recent cards, active collections, draft games, published objects, search, and a prominent Create action. Search covers title, field text, kind, collection, classification, author, asset, and publication state.

Creation gateway

The first question is “What are you making?” Options are one card, stack or deck, game, and series. Each path starts with an opinionated template and sample content. A user may skip design customization and still obtain a complete card.

Card editor

Desktop layout:

┌ title · mode · save state · preview · publish ┐
├ card browser ┬ card surface ┬ inspector       ┤
│ context      │ active view  │ fields/layers  │
├──────────────┴──────────────┴─────────────────┤
│ surfaces · revisions · related cards          │
└────────────────────────────────────────────────┘

Content mode

Presents kind-specific semantic fields, validation, classification, source, and alternative text. Selecting a field highlights every bound layer. Content mode is the default for a new card.

Design mode

Presents the active surface, template slots, layers, typography, imagery, background, and alignment. The default toolbar contains select, text, image, background, symbol, number, border, and AI-assist. Semantic values remain bound to fields.

Publish mode

Presents validation, visibility, canonical path, preview surfaces, social metadata, remix policy, export, and publish history. Publish is disabled with specific reasons rather than a generic error.

Inspector behavior

With nothing selected, show card kind, status, visibility, template, classification, collection context, and last revision. With a layer selected, show its field binding before visual controls. Meaningful image controls include alt text and rights. Game cards expose role and values. Published cards expose their pinned revision and public URL.

Stack builder

  • Grid view prioritizes visual scan and drag ordering.
  • List view prioritizes sequence and editorial metadata.
  • Table view prioritizes bulk creation, copy/paste, validation, and field comparison.

All three are views of the same membership data. Reordering must announce the new position and offer keyboard alternatives. Bulk edits provide a preview and one reversible transaction.

Game builder

The prompt-response builder has Setup, Cards, Playtest, and Publish sections. It shows counts and structural warnings. Playtest uses the production state machine with a local or isolated session; it is not a separate rules implementation.

The live game view adapts by role:

  • host sees lobby controls and public table state;
  • players see public table plus their own private hand;
  • spectators see public state only.

Public views

A public card page foregrounds the selected surface, followed by accessible content, author, collection memberships, provenance, and permitted remix, share, and export actions. A stack page supports grid and sequence. A series adds previous/next and archive. A game page offers description, card counts, join/start, browse, and remix.

Public views must feel like native destinations, not database records wrapped around a screenshot.

Responsive behavior

Mobile creation focuses on fields, template choice, preview, publish, and gameplay. The desktop inspector becomes a bottom sheet. Full spatial layer editing may be read-only on small screens, but every layer property remains editable through form controls. Tables become column-selectable records rather than horizontally compressed grids.

Accessibility

  • Use semantic headings, forms, buttons, lists, and tables before ARIA.
  • Maintain a visible focus indicator and logical focus order.
  • Offer keyboard commands for surface and slide navigation without trapping Tab.
  • Announce save, validation, reorder, generation, and publish state changes.
  • Provide non-spatial equivalents for drag, resize, crop, and reorder.
  • Respect reduced motion; never auto-advance cards or slides.
  • Expose card reading order independent of layer coordinates.
  • Validate text contrast and non-text interaction contrast.
  • Preserve zoom up to 200% without loss of function.

Empty, loading, and failure states

Every empty state offers one contextual next action. Long operations show progress and allow safe dismissal. A failed save retains local edits. A failed generation does not create an asset. A publication error cannot partially advance the public pointer. Offline edits are either explicitly unsupported or clearly queued; the interface must not pretend they are saved.