Skip to content

Finish partner-configurable field labels and contextual help #74

Open

Description

@BryceStevenWilley

Remaining RC1 work

Illinois partners requested a reusable way to customize field labels, contextual help text, and resource links by jurisdiction. Vermont testing additionally found confusing upload/document labels and court terms. The objective is plain-language assistance at the specific decision, not a wall of global explanations.

Foundation already shipped

These pieces do not by themselves demonstrate that an Illinois partner can override a given input's label and help without changing a template. This issue now tracks that remaining configuration and chosen initial fields rather than rebuilding existing page guidance.

Acceptance criteria

  • Confirm with Illinois/Vermont partners an initial prioritized list of confusing individual fields (screenshot annotations are welcome); pick a manageable RC1 set.
  • Provide a documented, jurisdiction-scoped way to override a field's visible label, help text, and authoritative resource link, supporting text inputs, selects/radios, and filing-type choices where applicable. Ensure labels remain tied to controls for screen readers and errors.
  • Apply the pattern to the prioritized fields in the Upload / Confirm / Organize documents / People paths. In particular, explain separate vs combined PDFs, valid filenames, main vs supporting documents, and court filing component versus a document attachment without pretending file splitting exists.
  • Use real court/partner-reviewed language and applicable link destinations rather than inventing legal rules. Different courts/filing types can receive different guidance where necessary.
  • Preserve default behavior for jurisdictions without overrides and test with desktop/mobile, keyboard, screen-reader labels, and translated or absent help.

Related / excluded

The original Illinois/Vermont feedback, including partner discussion of which screenshots to annotate, remains in the issue comments.

Activity

  1. nonprofittechy commented on Aug 28, 2026

    @nonprofittechy
    Member

    Illinois requested that jurisdiction partners be able to customize not only help text/resources but also the user-facing field label for essentially any input. Please treat per-field label overrides, help copy, and resource links as reusable jurisdiction configuration. Conditional county/court warnings are split into #198.

  2. nonprofittechy commented on Aug 28, 2026

    @nonprofittechy
    Member

    @mnewsted — tagging for visibility on this Illinois feedback item.

  3. nonprofittechy commented on Sep 25, 2026

    @nonprofittechy
    Member

    Vermont feedback — Kris, September 24, 2026: upload and document-label guidance

    Kris tested a Small Claims Answer package as an inexperienced e-filer, having accidentally selected Start a new case. This adds concrete acceptance criteria to the existing help-text work; it does not replace the Illinois requirements above.

    What the current code already does

    Static review of main at c2fd52b2d437e64644b7878a6c2c7dd9c3770c34 (not a reproduction of the deployed test session):

    • upload_documents.html already accepts multiple PDFs and says the user can leave during analysis. Its opening paragraph nevertheless introduces choosing the main document before that decision is needed.
    • organize_documents.html has an editable, required Document name initialized from the uploaded name, but no nearby explanation of whether to change it.
    • ui_text.py already distinguishes the overall main document from a per-document court component. The remaining usability problem is that “Court filing component,” “Lead Document,” and “attachment” still are not understandable to a first-time filer. This is a plain-language follow-up to completed Clarify “main document” versus Tyler “Lead Document” filing components #173, not a request to undo required court components.

    Additional acceptance criteria

    • At upload, explain whether each form should be a separate PDF, distinguish that from uploading several files together, and give an honest next step for a combined packet. Do not promise automatic splitting that is not supported.
    • Explain any actual filename restrictions and whether a name needs to be included. Do not suggest adding unnecessary personal information; give a simple example such as small_claims_answer.pdf if valid for the supported workflow.
    • Remove/defer “you can choose the main document later” from the initial upload instructions; explain that choice where it is made instead.
    • At Document name, say whether renaming is optional, what the court will see, and whether changing this label affects the original filename or PDF contents. Verify those semantics against the submission payload, and preserve an acceptable existing name without requiring an edit.
    • Explain the overall main document, each document's court filing component, and an attachment in ordinary language at the relevant controls. Use an Answer example for a subsequent Answer filing rather than implying that every filing starts a new case; preserve valid required-component behavior from Clarify “main document” versus Tyler “Lead Document” filing components #173.
    • During analysis, use reassuring wording such as “This may take a minute. You can leave this page and come back if you need to.” Keep the separate instruction to remain on the page while file bytes are still uploading; do not show analysis status when analysis has finished.
    • Add rendered-copy coverage for Vermont and a generic/other-jurisdiction fallback, and check keyboard/screen-reader access to the help. Include a first-time-filer check that these instructions answer the questions without needing court-system terminology.

    Implementation suggestion

    Reuse the existing ui_text registry/state overrides for jurisdiction-dependent instructions and gettext for shared copy, placing the help next to each decision. This can be a copy/template change without altering filing codes or payload semantics.

    Separate owners: PDF flattening/preparation is #113; early fee-waiver upload instructions and the later payment choice are #79; form-name-to-filing-type discovery, including “Document” versus “Other,” is #94.

  4. nonprofittechy commented on Oct 1, 2026

    @nonprofittechy
    Member

    @mnewsted can the ILAO/AOIC team identify at least a tentative (80%?) list of where you want to add explanations? A good way could be to add markup to screenshots of the current interface. I'm not really sure how best to tackle this one right now.

  5. mnewsted commented on Oct 1, 2026

    @mnewsted

    @nonprofittechy sounds good. is any time good to start documenting this? just want to make sure we're identifying places/elements on a stable candidate. thanks!

  6. nonprofittechy commented on Oct 1, 2026

    @nonprofittechy
    Member

    Some things might move around, but I think I can limit need for any re-work on this on your part regardless. If you let me know exactly what kind of changes you want, even if it's not a comprehensive list, at least I'll know where to let you customize things. And I'll try to build patterns out from there.

    For that reason, you don't have to get it 100% right at this point. I'm just not quite sure where to start yet. I promise you'll have a chance for another pass at it if things change and you decide to request more customization controls than the first version.

    [Edit: in other words, I think you could start this now]

  7. changed the title [-]Add help text per text field for all inputs and selections[/-] [+]Finish partner-configurable field labels and contextual help[/+] on Oct 13, 2026
  8. nonprofittechy commented on Oct 13, 2026

    @nonprofittechy
    Member

    What partner input would help us move this forward?

    Illinois and Vermont partners: We can start with a short, imperfect first list now. You do not need to wait for the interface to be final, document every field, or write polished text before responding. Even 3–5 high-impact examples will tell us where to build the reusable customization controls.

    For each confusing field or question, please share:

    1. Where it appears: the screen/page and exact field or button (an annotated screenshot is ideal). Note the state or court if it varies.
    2. What's confusing: what a first-time filer might misunderstand or do incorrectly.
    3. What would help: a suggested replacement label, one or two sentences of nearby guidance, or simply the explanation you want users to receive. Rough wording is fine; we can help edit it.
    4. Any official resource: a court-approved link or reference we should point to, if there is one.
    5. Priority: which examples matter most for launch.

    Example of a useful response: “Vermont → Organize documents → ‘Court filing component.’ A first-time filer does not know how this differs from an attachment. Please add plain-language guidance and an example for filing a Small Claims Answer; the exact text still needs court review.”

    Easiest next step: Reply here with the top 3–5 screenshots/fields (or link a shared document). We'll turn that into a proposed first implementation and return it for another partner review; additions can come later. The development team will handle the configurable field-label/help mechanism—partners need not edit YAML or GitHub code. See the Vermont examples already documented above for possible starting points.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions