Forms: suggestions and auto-completion in most fields the person fills #1251

New issue

Open

opened 2026-11-13 10:43:30 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-11-13 10:43:30 +00:00

Owner

The need

A way to ask less of the person (the aim of #1250): suggest or complete what they are about to type in most fields, so a form is filled by choosing rather than typing, and what is typed stays consistent (one spelling of a city, a company, a job title, a skill). The person can always type something else; a suggestion is never imposed.

What exists today

Some fields already suggest: skills from ESCO (jobs/esco.py), industries from NACE (jobs/industries.py), a few <datalist> or combobox uses (the phone widget, the industry list, address place, share and move-owner pickers), and the Annuaire / Wikidata lookups for companies. There is no common mechanism, so each one works its own way and most fields (a job title, a city, a company name, a contact's role, a source, tags) suggest nothing.

Wanted

One suggestion component (a cotton component and a small endpoint contract) that any text field can use: type, see a short list, pick with the keyboard or the pointer, or keep what was typed. It is an ARIA combobox (listbox, aria-activedescendant, announced result count), works without script as a plain field, and never blocks submit.
Where the suggestions come from, in order of preference, all of them the person's own data first:
1. Their own earlier entries (job titles, cities, companies, contact roles, sources, tags, skills, employers on the CV), most recent and most used first. This costs nothing and needs no network.
2. Reference data already in Postulo: ESCO occupations and skills, NACE industries, the GeoNames cities (when loaded), countries and languages, in the reader's language.
3. Lookups the person has enabled (the register lookup and Wikidata, #879): offered only when enabled, never fetched on each keystroke without a delay and a limit, and never sent anything the person has not typed into that field.
Dependent suggestions: choosing a company suggests its known location, careers URL and contacts; choosing a city fills the postcode and country (and the country then follows #1249); choosing a job title suggests the usual contract type. These fill but never overwrite what is already typed, and show what was filled so it can be undone.
Privacy: suggestions from a person's data are computed on the server for that person only, never cross accounts or shares unless the record is already visible to them; a lookup is a request to a third party and follows the setting that enables it.

First fields to cover (by how often they are filled)

Application: company, job title, source, location, contract type. Company: name, city, country, industry, website. Contact: name, role. CV and career: employer, title, school, skills, languages. Documents: template and tags.

Performance and limits

Debounced (about 250 ms), at most ten results, a short cache per field, an index on the columns searched; no suggestion request on page load; results for a field are a plain HTML fragment (htmx), consistent with the rest of the interface.

Tests

The component's keyboard and screen-reader behaviour (axe, announced counts), no-script fallback, right-to-left; the suggestion sources return only the person's data; a dependent fill does not overwrite typed text; the lookups stay off unless enabled; the request volume per keystroke is bounded.

Strings go through Weblate only. Related: #1250 (the study this serves), #1249, #1245, #879, #1248.

## The need A way to ask less of the person (the aim of #1250): **suggest or complete what they are about to type in most fields**, so a form is filled by choosing rather than typing, and what is typed stays consistent (one spelling of a city, a company, a job title, a skill). The person can always type something else; a suggestion is never imposed. ## What exists today Some fields already suggest: skills from ESCO (`jobs/esco.py`), industries from NACE (`jobs/industries.py`), a few `<datalist>` or combobox uses (the phone widget, the industry list, address place, share and move-owner pickers), and the Annuaire / Wikidata lookups for companies. There is no common mechanism, so each one works its own way and most fields (a job title, a city, a company name, a contact's role, a source, tags) suggest nothing. ## Wanted - **One suggestion component** (a cotton component and a small endpoint contract) that any text field can use: type, see a short list, pick with the keyboard or the pointer, or keep what was typed. It is an ARIA combobox (listbox, `aria-activedescendant`, announced result count), works without script as a plain field, and never blocks submit. - **Where the suggestions come from**, in order of preference, all of them the person's own data first: 1. **Their own earlier entries** (job titles, cities, companies, contact roles, sources, tags, skills, employers on the CV), most recent and most used first. This costs nothing and needs no network. 2. **Reference data already in Postulo:** ESCO occupations and skills, NACE industries, the GeoNames cities (when loaded), countries and languages, in the reader's language. 3. **Lookups the person has enabled** (the register lookup and Wikidata, #879): offered only when enabled, never fetched on each keystroke without a delay and a limit, and never sent anything the person has not typed into that field. - **Dependent suggestions:** choosing a company suggests its known location, careers URL and contacts; choosing a city fills the postcode and country (and the country then follows #1249); choosing a job title suggests the usual contract type. These **fill but never overwrite** what is already typed, and show what was filled so it can be undone. - **Privacy:** suggestions from a person's data are computed on the server for that person only, never cross accounts or shares unless the record is already visible to them; a lookup is a request to a third party and follows the setting that enables it. ## First fields to cover (by how often they are filled) Application: company, job title, source, location, contract type. Company: name, city, country, industry, website. Contact: name, role. CV and career: employer, title, school, skills, languages. Documents: template and tags. ## Performance and limits Debounced (about 250 ms), at most ten results, a short cache per field, an index on the columns searched; no suggestion request on page load; results for a field are a plain HTML fragment (htmx), consistent with the rest of the interface. ## Tests The component's keyboard and screen-reader behaviour (axe, announced counts), no-script fallback, right-to-left; the suggestion sources return only the person's data; a dependent fill does not overwrite typed text; the lookups stay off unless enabled; the request volume per keystroke is bounded. Strings go through Weblate only. Related: #1250 (the study this serves), #1249, #1245, #879, #1248.

tiagoagueda added this to the 0.6.0 milestone

2026-11-13 10:43:30 +00:00

tiagoagueda added the

accessibility

interface

enhancement

labels

2026-11-13 10:43:30 +00:00

tiagoagueda referenced this issue

2026-11-13 10:43:30 +00:00

Study: where Postulo shows or asks for more than the person needs #1250

tiagoagueda referenced this issue