Introducing the Locator
If you have developed even a single business application, chances are you have solved the same problem many times.
You have built a customer search dialog.
You have implemented product autocomplete.
You have written a custom editor for a data grid.
You have created a selection popup.
Every time, you were essentially solving the same problem.
Yet most UI libraries do not treat this requirement as a distinct concept. It usually appears as a lookup, an autocomplete, a popup dialog, or some other widget. The implementation changes, but the underlying problem remains exactly the same.
In this article, I would like to suggest that this recurring requirement deserves to be recognized as a fundamental concept of business applications. I will call it a Locator.
A Problem Found in Every Business Application
Almost every business application contains fields that reference other business entities.
A sales order references a customer.
An invoice references a supplier.
A warehouse transaction references a product.
A journal entry references an account.
In the database, these relationships are stored as stable identifiers. Users, however, never think in terms of CustomerId or ProductId. They think in terms of customer codes, names, tax numbers, barcodes, and other business identifiers that are meaningful to them.
The real problem is therefore not how to store an identifier.
The real problem is how users can locate the correct business entity using the information they already know.
Why a ComboBox Is Not Enough
When the dataset is small, a ComboBox is an excellent solution.
Countries.
Currencies.
Units of Measure.
Payment Methods.
These are reference tables containing a few dozen or perhaps a few hundred rows. Loading them into memory is perfectly reasonable, and selecting an item from a list is both fast and convenient.
The picture changes completely when we talk about Customers, Products, Suppliers, or General Ledger Accounts. Here the number of records may reach thousands—or even hundreds of thousands.
At this point, the problem is no longer selecting an item from a list.
The problem is locating the correct record.
And that is an entirely different problem.
The Locator
Most UI libraries provide general-purpose controls such as TextBox, ComboBox, ListBox, DataGrid, and TreeView.
Business applications, however, need something different.
They need a mechanism that allows users to locate a business entity using the information they naturally recognize, rather than its technical identifier.
This mechanism is what I call a Locator.
Its purpose is not to display a list.
Its purpose is not to suggest possible values.
Its purpose is to resolve a business reference.
A Locator Does Not Simply Return a Value
At first glance, a Locator may look like an advanced lookup control or an autocomplete widget.
In reality, it does something far more important.
It does not simply return a value.
It resolves a business reference.
Consider a sales order line containing a ProductId field.
The user searches for a product by typing its code or description.
Once the correct product has been selected, the application usually needs much more than the ProductId.
It may need the unit price.
The unit of measure.
The VAT rate.
The discount category.
It may even need different information depending on the customer, the company, the warehouse, or any other business context in which the search takes place.
A Locator therefore does not simply return a value.
It returns the result of resolving a business reference within a specific business context.
That is why it is much more than an advanced lookup control.
It Is Not a Control. It Is a Behavior.
This is perhaps the most important idea.
A Locator is not a particular user interface control.
It is a behavior.
In a desktop form, it may appear as two searchable fields.
In a data grid, it may be implemented as a custom cell editor.
In a web application, it may appear as an autocomplete field with a popup results list.
In a mobile application, it may open a dedicated search screen.
The appearance changes.
The behavior remains exactly the same.
User input
Code
Name
VAT
Barcode
│
▼
Locator
Searches
Disambiguates
Resolves
│
▼
Target Context
Key
Display values
Business values
The User Experience
Experienced business application users work almost entirely with the keyboard.
A good Locator should never interrupt that workflow.
When a search produces a unique match, the selection should be completed immediately.
Only when multiple possible matches exist should the user be asked to choose the correct business entity.
A Locator is not only about searching.
It is also about disambiguation.
Why Every UI Library Should Include a Locator
Every serious business application solves this problem every day.
Yet most UI libraries do not recognize it as a fundamental abstraction.
Instead, every application ends up implementing search dialogs, autocomplete controls, custom editors, and selection popups over and over again.
The functionality is essentially the same.
Only the implementation differs.
I believe that the Locator represents a fundamental concept of business applications, one that is still treated primarily as a collection of unrelated UI widgets.
Perhaps it is time to recognize it for what it really is: a fundamental abstraction for building data-entry and business applications.
Because in business applications, the critical concept is not displaying a list.
It is enabling users to locate the correct business reference.
In the next article, I will leave philosophy behind and move on to architecture.
What information should a Locator know?
How should it be described?
And how can the same definition be reused across forms, data grids, and different user interface technologies?
Top comments (0)