D7M.CO™
Index
عربيLet’s talk

SnapDrop Offline

My role
Product concept and requirements

I developed a product concept for sharing a file with someone nearby when there is no internet connection. I wrote the first-phase requirements so the sender could start from the Android share sheet and the recipient could download the file in a browser without installing an app.

Original SnapDrop product requirementsPDF
Read larger text 169 KiB · 4 pp
PreviousPage 2 of 4Next
Downloads and other formats
Original SnapDrop product requirements · Local hosting, NFC handover, teardown and technical architecture · Page 2 of 4

Local hosting, NFC handover, teardown and technical architecture

Discuss my SnapDrop Offline experience

The work in detail

  • I defined separate needs for the sender and recipient. The sender should be able to select a file in the app they already use. The recipient should be able to download it with minimal setup.
  • I specified a temporary local hotspot for the transfer. I proposed using NFC to share the connection details, then serving a download page from the sender’s device.
  • I wrote requirements for interruptions during the transfer, including an unavailable NFC handoff or a connection that drops before the download finishes.

First-phase requirements

From the original product requirements · SnapDrop Offline (Tap-and-Send) · Phase 1 Core · p. 1, section 3.1
“Transfer Overlay: Display a modal dialog presenting the file thumbnail, name, extension, and formatted size.”

The following summary describes the proposed sending and recovery flow for phase one.

From file selection to download
  1. The sender selects a file from the Android share sheet. Their device starts a temporary local network for the session.
  2. The recipient obtains the network details through NFC. If that handoff fails, they can scan a QR code displayed on the sender’s screen.
  3. The recipient joins the local network and opens the download page in a browser. The file travels between the two devices over that network.
If the connection drops

I proposed keeping the session available for three minutes after an interruption so the recipient could reconnect. That interval is part of the product specification.