Progressive Typing
Posted: Tue May 14 2024 11:39 am
Before we had a mouse we had progressive typing drop-list fields. When you entered the field and hit a key a list of potential matches appeared below it. When you hit the next keystroke the list adjusted containing only entries having the first two. Each character was added to the selection criteria for the list shown. When there was only one it would either auto-complete or you could tab complete it. Even back in the days of DOS, every UI library I used operated in this manner.
Today's UI libraries make it impossible to have good design. When you are in a combobox (or other type of list) they employ one & done keystroke support. Please allow me to provide a small example. Say you need to purchase a Carburetor. When you tab to the part selection list/combobox you start by typing "c".
In today's world a list of all things starting with C appears. Same thing happens in the world of good design.
Now you type "a"
In today's world a list of all things starting with A appears. In the world of good design the list now has only entries containing "ca." (Some designs require it be in the beginning and other designs allow for it to be anywhere in the word.)
Now you type "r"
In today's world a list of all things starting with R appears. In the world of good design the list now has only entries containing "car."
When you get down to a list of one, some shops would autocomplete, most shops would still require the user to TAB out because if you autocomplete they can't backspace to fix a spelling error.
I would like to see the following properties/settings added to all widgets having lists and entry fields so good design can happen out of the box without having to sub-class then gut private class code not exposed to the user for general override.
Perhaps a whole new widget so those who like the way the combobox currently works won't be offended?
QListBox or QListEntry?
Has all the properties requested above but appears (and is) a QLineEdit with additional property optionally requiring entry be in the list currently attached (allows for new data if not). When a user navigates to it the thing drops down (or pops above depending on screen position and remaining space) Re-use QListView or whichever existing list widget that can be most easily connected to a database table for data source if developer needs/wants.
Let the team think on this a bit.
Today's UI libraries make it impossible to have good design. When you are in a combobox (or other type of list) they employ one & done keystroke support. Please allow me to provide a small example. Say you need to purchase a Carburetor. When you tab to the part selection list/combobox you start by typing "c".
In today's world a list of all things starting with C appears. Same thing happens in the world of good design.
Now you type "a"
In today's world a list of all things starting with A appears. In the world of good design the list now has only entries containing "ca." (Some designs require it be in the beginning and other designs allow for it to be anywhere in the word.)
Now you type "r"
In today's world a list of all things starting with R appears. In the world of good design the list now has only entries containing "car."
When you get down to a list of one, some shops would autocomplete, most shops would still require the user to TAB out because if you autocomplete they can't backspace to fix a spelling error.
I would like to see the following properties/settings added to all widgets having lists and entry fields so good design can happen out of the box without having to sub-class then gut private class code not exposed to the user for general override.
- Enable progressive typing
- case sensitive/insensitive text match for list construction
- Beginning of word match
- Contained in word match
- Auto-complete if only 1
Perhaps a whole new widget so those who like the way the combobox currently works won't be offended?
QListBox or QListEntry?
Has all the properties requested above but appears (and is) a QLineEdit with additional property optionally requiring entry be in the list currently attached (allows for new data if not). When a user navigates to it the thing drops down (or pops above depending on screen position and remaining space) Re-use QListView or whichever existing list widget that can be most easily connected to a database table for data source if developer needs/wants.
Let the team think on this a bit.