Six things the signed-in journey got wrong on a phone - #395
Merged
Merged
Conversation
Measured at 390x844 in Chromium before and after, with a real PDF uploaded through the page. /sign The hero is the pitch for a visitor who has not started. It stayed at full height above every step, and at 390px that put the whole uploaded PDF below the fold: the first page started at y=1231 of an 844px screen. sign-flow.js now stamps the active step on <body> and the page collapses the hero to one line from the step after the document is chosen, in CSS. First page now starts at y=915, and at 1440 it is above the fold. The chosen file was named nowhere on the place step. huur.pdf went in and never appeared. Name and size now sit next to the document, with the full name in the title so a long one is readable. The sticky Back/Continue bar is opaque, so content scrolled underneath it unreadably: at 1440 the edit hint ended 7px under the bar. The scrolling content reserves the bar's height, and the buttons clear a phone's bottom safe area. /dashboard An empty document list said "No open requests" and offered no way out. The one action that fills the list is now a button in it. Send is not offered there: this list counts signing requests, not deliveries. Tap targets at 390px: filter chips and Refresh 36px, the four quiet links 36px, the footer links and "help centre" 19px, "What ParaSign is" 18px. All 44px now, through padding. The type keeps its size and the start card stays where it was, at y=348. The document reference was sliced to ten characters in code, so env_waiting_abcdefghijklmnop rendered as "env_waitin": a fragment that looks like a whole value and is useless read out to support. The full value is in the row and in the title, and CSS shortens it with an ellipsis when it does not fit. user-dashboard-documents pins the reference, the empty-state button and the 44px minimum. The access-log fixture follows the sign-flow.js cache-buster, which the one-version rule requires.
The file name and size went on the Place step, and request-signatures does not visit it: onDocChosen sends that mode straight from the picker to the co-signers. A customer picked a file, typed two addresses and pressed "Send for signature" with no screen in between saying what he was sending. The line moves out of the step and above them, so it holds on every step after the file is chosen, in all three modes. It hides on the two steps that name the file themselves: the hash-only card, and the finished screen, where the name is the signed one. tests/sign-document-identity.test.mjs drives the three modes in Chromium at 390x844 and asserts the line is visible, in the viewport and not inside a hidden step. With the line back inside the Place step, the two invite checks fail. Also on the dashboard, from the same review: Three links inside the answers were still under the minimum at 390: 19px for one at the end of its line, 41px for the two others. The phone rule now covers them, and the tap check reads every link in the list rather than the first. .dh-doc-ref set display and vertical-align that never applied: .dh-document-name span is more specific and had already made it a block. The selector now carries the class it needs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Six findings from the koper review of the signed-in journey, measured at 390x844 and 1440x900 in Chromium, before and after, with a real PDF uploaded through the page. A second commit answers the re-review.
/sign
1. The hero stood above every step. It is the pitch for a visitor who has not started, and at 390px it kept the whole uploaded PDF below the fold: the first page started at y=1231 of an 844px screen.
setActive()in sign-flow.js now stamps the active step on<body>asdata-ds-step, and sign.html collapses the hero to a single line from the step after the document is chosen. CSS only, no script in the page.2. The file was named nowhere. huur.pdf went in and appeared on no screen until the review step. Name and size now sit above the steps, with the full name in the
titleso a long one stays readable.The re-review found the half of this that the first commit missed. The line went on the Place step, and request-signatures never visits it:
onDocChosen()sends that mode straight from the picker to the co-signers. So a customer picked a file, typed two addresses and pressed "Send for signature" with nothing on screen saying what he was sending. The line now lives above the steps rather than inside one, so it holds on every step after the file is chosen, in all three modes. It hides on the two steps that name the file themselves: the hash-only card, and the finished screen, where the name is the signed one.3. The sticky action bar covered content. Back/Continue is opaque, so whatever sat under it while it was stuck could not be read. Measured at 1440: the edit hint ended 7px under the bar. The scrolling content now reserves the bar's height, and the buttons clear a phone's bottom safe area (
env(safe-area-inset-bottom)). Both sizes: no overlap at any scroll position./dashboard
4. The empty list was a dead end. "No open requests" was two sentences and no way out. The one action that fills the list is now a 44px button in it, to
/sign?mode=invite. Send is deliberately not offered there: this list counts signing requests, not deliveries.5. Tap targets at 390. Measured before: filter chips and Refresh 36px, the four quiet links 36px, the footer links and "help centre" 19px, "What ParaSign is" 18px. The re-review added three more, the links inside the answers: 19px for the one at the end of its line, 41px for the two others. All 44px now, and through padding: the type keeps its size. The dashboard fold is unchanged, the start card sits at y=348 before and after, and horizontal overflow stays at 0.
The site already had a 44px rule for these, keyed on
pointer: coarse. A phone-width viewport without touch emulation, which is what a review browser is, never matched it. The rules here are keyed on width, in each page's own stylesheet, so nothing outside /sign and /dashboard moves.6. The reference was cut mid-word. dashboard.js sliced the id to ten characters, so
env_waiting_abcdefghijklmnoprendered as "env_waitin": a fragment that looks like a whole value and is worthless read out to support. The full value is now in the row and in thetitle, and CSS shortens it with an ellipsis when it does not fit. The rule carries.dh-document-name .dh-doc-ref, because.dh-document-name spanis more specific and had quietly won over the bare class.Gates
first-screen, ui-truthfulness, site-claims, seo-contract, links, navigation-shell, frontend-loading-contract, pricing-fold, cache-bust, csp-inline, static-sanity, check-test-declarations, eslint, app-contrast, app-theme, apply-nav-idempotent, user-dashboard-documents, developer-parasign-dashboard: all green. sign-full 33/33, and every browser suite in the sign-e2e job, 42 passing.
Two suites carry the findings.
tests/sign-document-identity.test.mjsis new: it drives all three modes in Chromium at 390x844 and asserts the document line is visible, inside the viewport and not inside a hidden step. Put the line back in the Place step and its two invite checks fail.tests/user-dashboard-documents.test.mjsgains three checks, for the reference, the empty-state button and the 44px minimum over every link measured, including the ones in the answers; drop.dh-ask-list afrom the rule and the tap check reports 19px and fails. All of them are geometry and attributes, which no existing assertion could see. The access-log fixture follows the sign-flow.js cache-buster, which the one-version rule requires.What is left
At 390 the first PDF page still starts 71px under the fold. The hero was the biggest cause and it is gone; what remains between the top and the document is the Place step's own toolbar: the edit tools take 160px and the seal choice 247px, on a 844px screen.
The proposal for the next round, not done here because it is editor surgery and a separate review: put the edit tools behind one "Add to the document" button that opens them, and move the seal choice (in the document, separate sheet, or both) below the PDF, where it is a decision about the output rather than a step before seeing the input.
Merging
frontend/dashboard.htmltouches #396 (the signed-in shell) on two adjacent cache-bust lines only,nav-auth.jsv7 anddashboard.jsv9. Whoever merges second keeps both bumps and runsscripts/check-cache-bust.shagain.