Drive — Engineering — Ethan McNamara

01

In plain English

What it is: A Google Drive connection for project files, so your organisation keeps the documents and Signal Studio keeps the related work organised.
How it works: You would add a file to a project. It stays in your Google Drive, while Signal Studio shows where it belongs and whether it can be opened.
Why it matters: To keep files under customer control and give teams one clear place to find them.

02

The product film

Your files already have a home. A task, a deliberate gesture and its result, inside a reconstructed Signal Studio. It plays on its own while it is on screen; pause it, scrub it, slow it down, or read it as stills.

Scene rendered by preview-drive.js · 42s · 5 beats · 3 stills

03

What it is worth

Use the storage you already have.

For teams already paying for Google Drive, this puts that storage to work inside Signal. Keep the original with your company and avoid maintaining another file library.

Your existing Google DrivePut the storage your company already uses to work.
One home for the originalKeep files together in your company’s storage.
Connected to the projectFind the document beside the work it belongs to.

04

How it is built

The whole film turns on one gesture: a document leaves the desktop and lands in a project. It is a single element moving under one transform, timed against the same clock as the caption that describes it, so the words and the picture cannot drift apart.

Position in the Drive gesture

smoothstep, clamped
cubic-bezier(0.5, 0, 0.5, 1)

Cursor reaches the file: 500ms
The document flies: 3700ms
Drop target releases: 500ms

The flight is one <code>translate3d</code> on one node. Nothing else in the scene moves, and no layout property is touched, so the browser composites it without a reflow. The paper is not a sprite: it is the same DOM element that ends up in the file grid, which is why the landing looks like an arrival rather than a swap.

The drop target dims for 500ms while the document is over it, then releases. That release is deliberately shorter than the flight — the interface should answer faster than a person can change their mind, and slower gestures should be the ones a person is still deciding about.

Every phase reads its progress from the film clock with <code>progress(t, from, to)</code>, so seeking backwards restores exactly the same frame. There is no accumulated state to get out of step.

05

The working model

The file and its project relationship have separate lifecycles. A confirmed provider file can become an attachment; a partial transfer cannot.

The boundary that matters Workspace permission and current Drive authority must both permit access. A stored file reference grants neither.

Two paths: Standard flow and Connection lost mid-upload · 5 stages each

06

How it fits together

A person acts, the system checks, a result follows — and one other path, for when the check does not pass. This describes proposed responsibilities and decisions, not deployed infrastructure.

Read the diagram source

%% Director-friendly architecture. Maturity and limits are recorded in accDescr.
flowchart TB
  accTitle: How Project Drive works
  accDescr: A project editor adds a file. Signal checks both workspace permission and access to the customer’s Google Drive. Drive stores the original file; Signal adds its project link only after storage is confirmed. Missing access or an interrupted upload leaves the attachment incomplete and calls for reconnection or retry. Implementation exists in development; live integration acceptance remains open.
  A(["Project editor<br/>Adds a file"])
  B{"Workspace and Drive<br/>access allowed?"}
  C("Customer Google Drive<br/>Stores the original")
  D{"File fully<br/>saved?"}
  E("Project file list<br/>Original file linked")
  X("Reconnect or retry<br/>Attachment stays incomplete")
  A --> B
  B -->|Allowed| C
  C --> D
  D -->|Confirmed| E
  B -->|Access unavailable| X
  D -->|Interrupted| X
  classDef human fill:#faf7f2,stroke:#bf8c53,color:#24211c;
  classDef work fill:#ffffff,stroke:#a3a5ad,color:#25262a;
  classDef decision fill:#f3efff,stroke:#967bcb,color:#30244c;
  classDef result fill:#f0f6ff,stroke:#7b9dca,color:#1d365b;
  classDef exception fill:#fff5ec,stroke:#ce9b63,color:#64431e;
  class A human;
  class C work;
  class B,D decision;
  class E result;
  class X exception;

07

The case study

A project platform can organise a file without becoming its permanent custodian.

The problem

Project attachments often become another copy in another SaaS account. Customers lose a clear source of truth, while the product inherits storage costs and the responsibility of keeping those copies accessible.

The insight

The useful product layer is the relationship between a file and the work. Storing that relationship does not require storing another copy of the file.

The system

A substantial implementation exists in the development workspace. The architecture separates provider file identity and project context from customer-owned file content. Server-mediated access, resumable uploads, and reconciliation address the external storage boundary; live OAuth, interruption, quota, and production migration acceptance remain open.

The rationale

Customer ownership can reduce duplicate storage and make the product easier to leave. The benefit depends on accepting an external provider as part of the critical path.

Responsibilities

Project context: File identity, project relationship, and visible availability state.
Access boundary: Server checks workspace permission and connected provider authority.
Customer Drive: File bytes remain in customer-controlled provider storage.
Reconciliation: Refresh availability without treating cached access as authorisation.

The boundary

A project reference grants no Drive permission. Signal Studio workspace access and the connected account’s provider access must both permit an operation.

The trade-off

Owning less storage means controlling less availability. The proposal favours explicit access states over pretending every attachment is always reachable; resumable uploads improve recovery but require durable session state and careful cleanup.

When it fails

Drive disconnects

Keep file names and project context available, mark the connection unavailable, and offer reconnection. Never display a stale cached permission as proof of access.

A file moves or disappears

Address the file by provider ID, not folder path. Recheck availability and explain a missing or inaccessible file without silently substituting a different document.

An upload is interrupted

Persist the resumable session and reconcile its offset before retrying. Create the project attachment only after the provider confirms the completed file.

Evidence Implementation in development · live integration acceptance remains open · local demonstration uses synthetic data

08

On the design side

The file surface was explored as part of the home deck: twenty answers to what the first screen should be, several of which lead with recent files rather than tasks.