Repository navigation
Add an OSM signup prompt to the reporting-method and app pages - #133
Conversation
Both reporting paths write to OpenStreetMap, but the only signup link lived in step 1 of the iD stepper, so anyone landing on /report or /app had no signal they needed an account until they hit the login wall. Adds a callout on the reporting-method page and a line under the app download CTA, both linking to openstreetmap.org/user/new. Closes FoggedLens#86.
|
Thank you for this - had forgotten there was an issue open for it, but it came up again recently. The new blurb on the app page is not as prominent, being at the bottom. |
|
Done in e8ab8ab. Went with your wording, About link included, and moved the note up into the hero right under the download buttons instead of the bottom CTA, so it reads before anyone installs. Dropped the old bottom copy so it doesn't show twice. Also pointed the OpenStreetMap mention in the reporting-page alert at the About page to match. Built clean locally. |
|
LGTM. @frillweeman ? |
kawacukennedy
left a comment
kawacukennedy
left a comment
There was a problem hiding this comment.
Reviewed the final state (e8ab8ab). This is a clean, well-scoped fix for #86 — it addresses the exact gap (users landing on /report or /app get no account hint) with minimal, dependency-free template + scoped-CSS changes. No blockers.
Verified:
npm run build-onlysucceeds cleanly on this branch (the >500 kB chunk-size warning is pre-existing and unrelated).- The
.hero-note a { color: inherit }rule is correct:.hero-sectionsetscolor: white(DeflockApp.vue:422), so the links will properly inherit white and read as links via the underline — the defaultlink-blueon that purple gradient would indeed have been hard to read. - Link text is descriptive, not "click here" — good for AT users.
- Wording is consistent with the existing CTA on
/report/id(ReportID.vue:26), so the site reads consistently across pages.
Two non-blocking notes, both minor:
-
Contrast (a11y). Normal text on the hero gradient needs ~4.5:1 to pass WCAG AA. White on the lighter end of
#667eea→#764ba2sits near 4:1, and the new.hero-noteaddsopacity: 0.85, which lowers effective contrast further. This matches the pre-existing.hero-subtitle { opacity: 0.9 }pattern, so it isn't newly broken — but while you're here, consider either dropping the opacity or bumping it (e.g.0.95) on the note so the small (0.95rem) account-CTA text stays comfortably legible. A quick run through a contrast checker against both gradient stops would confirm. -
rel="noopener". The two newtarget="_blank"links (and the identical pre-existing link inReportID.vue:26) omitrel="noopener", while a few other links in the repo (OSMTagSelector.vue:40,Groups.vue:40) include it. Modern browsers treattarget="_blank"as implicitlynoopener, so this is a consistency nit rather than a defect — but addingrel="noopener"to these new links (and ideally the matching one on/report/id) would bring them in line with the safer convention.
None of this blocks merge — the change does what it sets out to do, cleanly. Nice, focused PR.
Phrasing
stopflock
left a comment
stopflock
left a comment
There was a problem hiding this comment.
Still LGTM. Altered phrasing on report page. Executive decision, merging.
Closes #86.
Both reporting methods write to OpenStreetMap, but the only "create an account" link on the site is buried in step 1 of the iD stepper on
/report/id. Someone landing on/reportor/appgets no hint they need an account until they hit the login wall. That's the gap the issue is pointing at.Two changes:
ReportChoose.vue— an infov-alertunder the intro line, before the two method cards, saying both paths save to OSM and linking toopenstreetmap.org/user/new.DeflockApp.vue— a line under the download CTA noting the same thing, since the issue asked about the app page too. That section sits on the purple gradient, so there's a small scoped rule making the link inherit white instead of rendering default-blue on purple.Wording matches the existing link on
/report/id. No new deps, no state, no telemetry.Checked with
npm run build-only(no bun here, andpackage-lock.jsonis in the repo so npm works) and rendered both pages againstvite dev.npm run type-checkdoes fail, but onApp.vueand a@vitejs/plugin-vuetype declaration. Both are already broken onmasterand neither is touched here.