The Signature That Scrolled The Page
On a phone, a signature is a swipe — and a swipe is exactly what every scrolling screen in the app also wants. Who wins that argument decides whether you get a signature or half a squiggle and a scrolled page.
The first version of any mobile signature pad fails the same way, and it fails in front of a customer. You hand the phone to the driver, he starts to sign, and about a third of the way through his finger the page jumps upward. What lands in the record is the first inch of a signature. He is now looking at you, holding your phone, and the honest thing to say is "sorry, do that again" — which is the sentence that gets a feature quietly abandoned within a fortnight.
A signature is a swipe
That is the whole problem in one line. A drag across the screen is the gesture that draws a signature, and it is also the gesture that scrolls a list, dismisses a sheet, swipes a tab and pulls to refresh. The signature pad does not sit alone on a screen — it sits near the bottom of a long movement form, inside a scrolling container, which is the one place where the gesture is guaranteed to be contested.
Somebody has to lose that argument, and by default the pad does. Scrolling containers on both Android and the web are built to assume that a drag belongs to them and that whatever is underneath will cope, because for every other control on the screen that assumption is correct.
The pad has to take the gesture and refuse to give it back. Everything else about signing on a phone is downstream of that one decision.
So in the Android app the pad claims the gesture at the moment a finger lands, declines every subsequent request to hand it over, and blocks the native responder underneath it for the duration of the stroke. The enclosing scroll view is not asked politely; it is shut out until the finger lifts. On the web the equivalent is telling the browser that touches on the canvas are not for scrolling at all, and then capturing the pointer so a stroke that wanders off the edge of the pad still belongs to the pad rather than being dropped mid-letter.
How to test this in thirty seconds
On any mobile signing feature, put the pad halfway down a long form and sign a wide, fast, looping signature that runs off the edge of the box — the way people actually sign, not the careful little squiggle a demo uses. If the page moves, if the stroke stops at the boundary, or if a second finger resting on the screen breaks it, you have found the bug that will retire the feature.
A tap is not a signature
The other thing a phone does that a desk does not is collect accidental contact. A device handed across a counter gets a thumb on the edge, a palm on the glass, a stray press while somebody works out which way up to hold it. Every one of those is, technically, ink.
Both of our pads independently require movement before anything is recorded. A press with no drag is discarded — not stored as a very small signature, not saved as a dot. This sounds pedantic until you consider what the alternative produces: a record that claims to carry a signature, with a single pixel of evidence on it, filed as proof that somebody accepted a delivery. A blank is honest; a dot is a lie with a timestamp.
Two pads, one contract
There are two implementations, because a browser and a native app do not share a drawing surface. What they do share is the output.
In the Android app
- Strokes collected as vector paths and drawn by the app's own SVG renderer.
- Deliberately not a WebView-based signature library — that is a lot of weight to add to a light app for one optional field.
- Rasterised to a PNG by the SVG view itself, on the frame after the stroke lands, so nothing new is linked into the build.
- If rasterising fails for any reason, the pad reports no signature and the stock movement proceeds regardless.
On the web
- Drawn on a canvas through pointer events, so a finger, a stylus and a mouse are all the same code path.
- Sized in layout pixels but drawn at the device's real resolution, so a signature taken on a high-density phone does not arrive looking like a marker pen.
- Resizing or rotating replays the existing strokes rather than clearing them, which is what makes rotating the phone mid-signature survivable.
- A pad inside a modal is re-measured when the panel opens — a hidden pad measures zero wide and would otherwise never get a drawing surface at all.
Both emit the same thing: a PNG encoded as text, handed to the screen that owns the movement. Neither pad submits anything itself, which is why the same component works on a check-in, a check-out, an adjustment, both ends of a stock transfer and an asset handover without knowing anything about any of them.
Why it travels as text and not as a file
This is the decision that makes signing work in the places signing actually happens, and it is worth being concrete about because it is the one thing a demo will never show you.
Attachments in the mobile app require a live connection. Try to add a photograph to a check-in with no signal and the app tells you so plainly, because a multipart upload of a file on disk is not something the offline queue can hold and replay reliably. That is a real limitation and we say so in the app rather than failing later.
A signature is not subject to it, because a signature is not a file. It is a string sitting in the movement payload beside the quantity and the reason — so it queues exactly like the rest of the movement, syncs exactly like the rest of the movement, and arrives whole. The same handover that cannot take a photograph in a dead zone can take a signature in one.
-
The finger lands
The pad claims the gesture from anything that might scroll, and starts a path at that point.
-
The path grows
Each movement extends the stroke, redrawn live so the person signing sees ink following their finger rather than appearing afterwards.
-
The finger lifts
If the path contains no movement it is discarded as a stray touch. If it does, the stroke is committed to the drawing.
-
The drawing becomes a PNG
On the next frame — the path has to reach the drawing layer before it can be rasterised — the whole signature is encoded as text.
-
It joins the movement
The encoded mark goes into the same payload as the item, the quantity, the location and the printed name of the signer.
-
It queues or it posts
With signal, it posts. Without, it waits in the offline queue as part of the movement and goes up when the device finds a connection. Nothing is stranded and nobody signs twice.
One deliberately awkward detail
On the web, the mark is encoded every time a stroke finishes rather than when the form is submitted. That is slightly wasteful and it is on purpose: the check-in and check-out screens run a confirmation step before they submit, and a value that is already written by the time that step runs keeps the pad out of that conversation entirely. A pad that serialises at submit time has to be taught about every confirmation dialog that might sit in front of it, which is a dependency that only ever grows.
What the device cannot give you
The gap between "we capture signatures on mobile" and what a forensic examiner would want is wide, and worth stating before somebody writes the former into a procedure.
What AWRA OpsHub does today
- A pad on the movement screens where handovers happen: check-in, check-out, adjustments, both ends of a stock transfer, and asset custody movements.
- A gesture that is claimed from any scrolling container, so a real signature drawn at speed does not scroll the page or break at the edge of the box.
- Accidental contact discarded — a press with no movement records nothing at all.
- Drawing at the screen's own resolution, with rotation and resizing preserving what has already been drawn.
- Capture with no connection, because the mark travels as text inside the movement rather than as a file upload.
- Finger, stylus or mouse through one code path, and a POS touchscreen behaves like any other touch device.
What it does not do
- No pressure or speed sensitivity. The line is a uniform width whether it is drawn with a thumb or a stylus, so the signature looks flatter than one on paper.
- No stroke data is retained. What is stored is a flat image, not the vector path or the timing behind it — so a signature can be looked at and compared by eye, and can never be examined the way a forensic document examiner would want.
- No specimen signature on file. There is nothing to compare a mark against, so the system cannot tell you whether a signature matches the person it names.
- No palm rejection beyond claiming the gesture. A hand resting on the glass while somebody signs can still interfere.
- No support for dedicated signature tablets. No USB or Bluetooth signing hardware; the device you already have is the device.
- Ordinary gloves do not work. A capacitive screen needs skin or a compatible stylus, which is a real constraint in a cold store or on a site.
Not ours, by choice
- Two implementations, one for the app and one for the browser, is a deliberate cost we carry rather than shipping a WebView inside the app to have a single one. It means two pieces of code have to keep behaving identically, and that is our problem to manage rather than yours.
The stroke-data point is the one to weigh if a signature matters legally to you. We store a picture of a signature. That is enough to show somebody their own mark, which settles most disputes, and it is not enough for anybody to prove it was theirs against their denial.
What is not built today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for the gap you just read about. Two honest qualifications so this is worth what it claims: a handful of gaps on this blog are deliberate refusals rather than missing work — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words rather than calling it a gap. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped gaps, which are the ones this blog admits most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsWhat to ask about anybody's mobile signing
Four questions, and what the answers tell you
Where on the screen does the pad sit, and what is around it?
What you will usually hear
A demo on a short, purpose-built signing screen.
How to read it
Ask to see it inside a long form. A pad on its own page has never had to win a gesture fight, and the version that ships will.
Does the pad run inside a WebView?
What you will usually hear
"It uses a standard signature library."
How to read it
Many of them wrap a browser. That works, and it costs app size and start-up time, and it tends to be where the scroll conflicts live. Not disqualifying — just know which one you are buying.
Can I sign with no connection, and can I attach a photo with no connection?
What you will usually hear
One answer covering both.
How to read it
They are different problems: a string can queue, a file upload usually cannot. A vendor who has not separated them has probably not tested the second one.
Do you keep the stroke data or just the image?
What you will usually hear
Silence, or "we store the signature".
How to read it
Almost everyone stores a flat image, us included. The reason to ask is to find out whether the vendor knows the difference before they tell your auditor it is forensically sound.
Our take
Mobile signature capture is not hard because drawing is hard. It is hard because the gesture is contested, the contact is accidental, the connection is missing and the device is being held by somebody who does not work for you. Get those four right and the pad is unremarkable, which is exactly what you want from something you hand to a stranger at a gate.
This is the fourth of four posts on handover signatures. The Squiggle Is Not The Evidence covers what a captured mark actually consists of, A Hundred Out, Ninety-Seven In covers why a stock transfer needs two of them, and The Approval That Needs No Pad covers where we refused to put one.
Frequently asked questions
Can I capture a signature on a phone or tablet?
Yes. The pad is built into the Android app on the check-in, check-out, adjustment, stock transfer and asset movement screens, and the same feature works in a mobile browser. A finger, a stylus or a mouse all work through the same code path, and a POS touchscreen behaves like any other touch device.
Why does signing sometimes scroll the page in other apps?
Because a signature is a drag, and a drag is also how you scroll. Unless the pad explicitly claims the gesture and refuses to give it back, the scrolling container underneath it wins and you get the first fraction of a signature. Ours claims the gesture on contact and blocks the container beneath for the duration of the stroke.
Can I sign with no internet connection?
Yes, and this is a deliberate design difference from attachments. Photographs require a live connection because a file upload cannot be reliably queued and replayed. A signature is not a file — it is text carried inside the movement payload — so it queues with the movement and posts intact when the device finds signal.
Does a stray touch create a signature?
No. A press with no movement is discarded rather than stored as a dot. A blank signature field is honest; a single-pixel mark filed as proof of delivery is worse than nothing.
Do you keep the stroke data for signature verification?
No. What is stored is a flat PNG image, not the vector path or the timing behind the stroke, and there is no specimen signature on file to compare against. That is enough to show a person their own mark — which is how handover disputes are actually settled — and not enough for forensic comparison. If a signature matters legally rather than operationally, that is the limitation to weigh.
Will it work with gloves on?
Only with capacitive gloves or a compatible stylus. An ordinary work glove will not register on a touchscreen, which is a genuine constraint in a cold store or on a site — worth knowing before you plan a procedure around it.
