swipefile.design
← Collections

CURATED COLLECTION · 5 REFERENCES

Five public app interfaces to study

A collection of design references, with notes and links to the originals.

Design notes

A form begins as a blank document with a title and inline starting choices, keeping editor chrome lighter than the content area.

Useful for: Unsigned initial form editor.

surface
Unsigned initial form editor.
nav
A slim top bar groups Customize, Preview, Publish, and account access.
layout
Wide document canvas with inline start, template, and import choices.
density
Low; most space is reserved for the document.
color
White, muted gray, blue action accents.
typography
Document-like sans text with a larger form title.
pattern
Make the empty state the first step of editing: type directly or choose a starting route.
states
Actual blank form state. No form was published or submitted.
dont
Do not hide the starting options behind a separate onboarding wizard.
Design adaptation prompt
# Design reference: Tally — Document-style form builder
Source: https://tally.so/create
Swipefile reference: https://swipefile.design/ref/tally-form-editor/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: Unsigned initial form editor.
- nav: A slim top bar groups Customize, Preview, Publish, and account access.
- layout: Wide document canvas with inline start, template, and import choices.
- density: Low; most space is reserved for the document.
- color: White, muted gray, blue action accents.
- typography: Document-like sans text with a larger form title.
- pattern: Make the empty state the first step of editing: type directly or choose a starting route.
- states: Actual blank form state. No form was published or submitted.
- dont: Do not hide the starting options behind a separate onboarding wizard.

Useful for: Unsigned initial form editor.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.
Design notes

A restrained discovery grid lets channels and individual blocks share a visual browsing surface, with simple type and sort controls above it.

Useful for: Public Explore feed of channels and blocks.

surface
Public Explore feed of channels and blocks.
nav
Search and account actions above View and Sort controls.
layout
Open filter area followed by a multi-column grid of image, text, and channel cards.
density
Moderate; imagery carries more weight than interface chrome.
color
White, light gray dividers, black text; color comes from saved blocks.
typography
Small neutral sans interface labels.
pattern
Keep mixed content types recognizable while allowing them to coexist in one browsing grid.
states
Public feed as captured; content and ordering change. Private channels were not accessed.
dont
Do not make every metadata field compete with the content preview.
Design adaptation prompt
# Design reference: Are.na — Explore channels and blocks
Source: https://www.are.na/explore
Swipefile reference: https://swipefile.design/ref/arena-explore/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: Public Explore feed of channels and blocks.
- nav: Search and account actions above View and Sort controls.
- layout: Open filter area followed by a multi-column grid of image, text, and channel cards.
- density: Moderate; imagery carries more weight than interface chrome.
- color: White, light gray dividers, black text; color comes from saved blocks.
- typography: Small neutral sans interface labels.
- pattern: Keep mixed content types recognizable while allowing them to coexist in one browsing grid.
- states: Public feed as captured; content and ordering change. Private channels were not accessed.
- dont: Do not make every metadata field compete with the content preview.

Useful for: Public Explore feed of channels and blocks.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.
Design notes

A large local time anchors a horizontal hour rail and comparison cards, making a time difference visible before users need to read a city list.

Useful for: Public time zone converter.

surface
Public time zone converter.
nav
Time and zone selectors across the top, plus a Share action.
layout
Large date and time, horizontal timeline, then city comparison cards.
density
Low around the current time, denser further down the city list.
color
Warm cream, dark navy, white cards, green primary utility action.
typography
Large tabular-looking time numerals with compact sans labels.
pattern
Establish one reference time and show the offset beside every comparison.
states
Live current-time state; this capture does not book or share a meeting.
dont
Do not rely on zone abbreviations alone when a city and relative offset can clarify them.
Design adaptation prompt
# Design reference: SavvyCal — Time zone comparison
Source: https://time.savvycal.com/
Swipefile reference: https://swipefile.design/ref/savvycal-time-zones/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: Public time zone converter.
- nav: Time and zone selectors across the top, plus a Share action.
- layout: Large date and time, horizontal timeline, then city comparison cards.
- density: Low around the current time, denser further down the city list.
- color: Warm cream, dark navy, white cards, green primary utility action.
- typography: Large tabular-looking time numerals with compact sans labels.
- pattern: Establish one reference time and show the offset beside every comparison.
- states: Live current-time state; this capture does not book or share a meeting.
- dont: Do not rely on zone abbreviations alone when a city and relative offset can clarify them.

Useful for: Public time zone converter.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.
Design notes

A narrow asset rail and compact toolbar surround a large empty canvas, with page and zoom controls anchored at the bottom.

Useful for: Public design editor, new untitled canvas.

surface
Public design editor, new untitled canvas.
nav
Left tool rail for assets, text, drawing, layers, and import; top actions for download and account access.
layout
Dark editor shell surrounding a light workspace and centered white canvas.
density
Low on the canvas, compact around the edges.
color
Dark charcoal chrome, gray workspace, white page.
typography
Small sans tool labels.
pattern
Keep tools at the edges and the artifact in the center; anchor zoom and page navigation consistently.
states
Actual empty canvas. No design was uploaded or exported.
dont
Do not mistake the empty canvas for a loading screen or fill it with invented customer work.
Design adaptation prompt
# Design reference: Polotno — Canvas and asset editor
Source: https://polotno.com/studio
Swipefile reference: https://swipefile.design/ref/polotno-design-editor/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: Public design editor, new untitled canvas.
- nav: Left tool rail for assets, text, drawing, layers, and import; top actions for download and account access.
- layout: Dark editor shell surrounding a light workspace and centered white canvas.
- density: Low on the canvas, compact around the edges.
- color: Dark charcoal chrome, gray workspace, white page.
- typography: Small sans tool labels.
- pattern: Keep tools at the edges and the artifact in the center; anchor zoom and page navigation consistently.
- states: Actual empty canvas. No design was uploaded or exported.
- dont: Do not mistake the empty canvas for a loading screen or fill it with invented customer work.

Useful for: Public design editor, new untitled canvas.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.