Icon Select
Presents a browsable, searchable set of icons for the user to choose from.
Where to find it
Architect Panel → Data:
- Datastores — the datastore, then Table Designer to add or edit a field
When to hand over the choice
- Configuration screens, where an administrator is defining categories, statuses or menu items.
- Personalisation, where the icon is the user's own.
- Anywhere the person choosing knows what it should mean better than you did at design time.
When not to
On ordinary data entry. A user filling in a case should not be choosing an icon for it — that is a decision that belongs to the case type, and asking for it produces inconsistency and slows them down.
If you find an icon select on a record-level form, the icon almost certainly belongs on a category instead.
Expect inconsistency
Given a free choice from a large set, people choose differently. Two administrators defining similar categories will pick different icons, and the result reads as unconsidered even though every individual choice was reasonable.
Where consistency matters, guidance helps more than restriction — a short note on the screen about which family to use, or a convention written down, will do more than hoping.
Search only helps if names match
Users search for what they mean — "customer", "money", "warning" — and icon names are frequently more literal, so the useful icon is often found under a name nobody would guess. Set expectations that browsing may beat searching.
The same accessibility rule
Whatever a user picks, the icon must not be the only signal. Ensure your display shows a label alongside it, because you cannot rely on somebody's choice being self-explanatory to anybody else.
Icons are not status
An icon chosen once and displayed is fine. An icon used to convey a changing state is a poor mechanism — it needs to be understood, cannot be reported on, and is easily missed.
Use a proper status field and let the icon hang off it.
Set a sensible default
Most people will accept it, which is a good thing here — a default that suits the common case produces more consistency than an empty field and better results than a random pick.
Worked example
An administration screen for case types uses an icon select, with a default and a note recommending the outline family. Individual cases have no icon field at all — they inherit their type's — so the icons stay consistent and case entry is one field shorter.
Recommendations
- Use it on configuration screens, not on data entry.
- Set a default and give a short convention.
- Always pair with a label on display.
- Never convey status with an icon alone.