|List Selection in Helix: macOS Spec Changes|
Helix list views allow the user to create an ‘ad hoc’ query by selecting one or more records on the list. Selected records can be:
|Helix History Lesson||
In the beginning there were “clickable lists” — double click a record in a list and a specified entry view is opened with that record. From there you were free to look at other records on the entry view.
Later “selectable lists” were introduced — you could now highlight multiple records and perform any of the actions mentioned above on them. Helix accomplished this by creating an ‘ad hoc query’ — called a selection query — containing only the selected records.
When an entry view is opened by double clicking on a list with selected records, the selection query is passed through to the entry view, allowing the entry view to show only the records that are part of the list selection, in the order they were selected. This makes it easy to edit specific records from a list while skipping others.
|Classic Helix Spec Oversight||
When the selectable lists feature was added, it created a conflict with the original “clickable” spec. Originally, double clicking a record opened the entry view, but “double click” is a shortcut for “open” so a conflict arose: when a single record is selected, then opened (via ‘open’ or double click) creating a selection query that restricts the entry view to just that one record would break the expectations of people used to double clicking a record and then moving from record to record on the entry view.
Therefore, a compromise specification was used in Classic Helix: If only one record is selected (whether by double click or by discreet click/open events) the selection query is ignored, but if two or more records are selected, the selection query is used to restrict the entry view to display only the selected records.
The first problem with this is that it makes Helix inconsistent: selecting one record in the list resulted in one behavior, while selecting two or more records had another behavior. The bigger problem with this is when the designer wants to create a sequence to do something such as “select the records you want to print and click this button to print them” with the idea that a sequence will open an entry view designed for printing and then do a Find and Print All command. This works great as long as the user selects two or more records, but if the user selects just one record, the selection query is not passed through, and Find and Print All prints every record available on the view, which could number in the thousands. A Print Selection scenario like this is bad enough, but a Delete Selection under these conditions would be disastrous.
|Changes for macOS||
The inconsistencies in the Classic specification for selected lists have been addressed as follows:
A single click, by itself, begins the selection process. The record is highlighted (light gray by default) to indicate that the mouse click was registered. If no secondary click (a double click) is detected, the record is ‘fully’ highlighted, by changing the selection color (to light blue by default).
Therefore, a single click followed by a pause is now interpreted as a selection, and the resulting selection query — containing just one record — is passed through to the entry view if it is subsequently opened. This effectively closes the loophole discussed above while retaining the double click behavior people are accustomed to.
A double click (two clicks without a pause) constitutes a simple “open” request, and no selection query is created or passed through. This allows old, learned behaviors to continue. The key interface change is that in this case, the feedback for a single click is a light highlighting; if a second click occurs on the record while that light highlighting is in effect, the specified entry view opens. In the case of a selectable list, one click turns into a selection event if there is no secondary click within the designated time span. (Designated by the user’s system preference -> mouse -> double click speed setting.)
As before, click-drag (currently unimplemented in macOS), shift-click, command-click all add to the selection query and extend the selection. The visual indication that a query has been formed is the highlighted record.
The color of the preliminary and secondary shading can be changed by editing the HxDimHiliteColor & HxStrongHiliteColor preferences. See this technote for more information on editing preferences.