|Enter vs. Return|
In working on the macOS (and cross-platform) transition, we discovered a wrinkle related to the similarities and discrepancies of the Enter key and the Return key. This survey is to solicit feedback on the direction Helix should take in the future.
The Overview section, which is normally found here and explains the problem in detail, has been moved to the bottom of this page. If you are not already familiar with the survey, you should read that before drawing conclusions from the results.
This survey ran May 1 – June 5, 2007.
138 users participated in this survey.
Unlike our other surveys, this one is really asking you to help us find the best way to solve a particular problem that may (or may not) present itself in the future. As opposed to ranking your need, this survey asks you to agree or disagree with the proposed solutions. One of the proposed solutions should strike you as the best for you; the others less so.
The bars below show the level of agreement you had with each option, according to your votes.
Unfortunately, four problems marred this survey:
Based on the distribution of votes, we plan on going with the middle option. Since we already have Enter vs Return key distinction working in our current builds, our first macOS products will ship with the distinction intact. However, if we come to a point where the effort to keep this distinction going becomes annoying, we will begin to phase this change in. That may be next year, or it may be never. Our current expectation is that this will probably happen when we update to the next version of wxWidgets.
Also, for those who continue to think that we invented this notion out of whole cloth, take a look at Apple’s Accessibility Guidelines. These guidelines specifically tie the Enter and Return keys together. As we said before: the writing is on the wall.
One of our engineers wrote:
A long long time ago in a galaxy far away, Apple had a return key on the main body of the keyboard and an enter key on the numeric keypad. IBM had an enter key on the main keyboard and an enter key on the numeric keypad…
IBM, due to the marketing (not technical) genius of Bill Gates, continued to gather market share and soon most of the world believed there was only a single enter key, with the one on the main keyboard and one on the numeric keypad performing identical functions.
Eventually Apple stopped trying to be distinct in this way and macOS now makes little distinction between the two keys. Meanwhile, Helix, locked in its ways, continues to demand that the enter key on the numeric keypad be used to enter a record into the database, while the return key on the main keyboard enters a literal return character (ASCII 13) in a text field.
Granting for the time being the wisdom in that position, I see no reason for Helix to continue to hold onto any other distinction. Looking a little bit further into the future, what will Helix do when it gets to the platform independent version, and the operating system provides no indication as to which of the enter keys the user actually pressed?
This sent us on an expedition, surveying all of the macOS applications we could find. The engineer is correct: with a few rare exceptions, macOS applications do not make a distinction between the return key and the enter key.
In most macOS applications a literal return character is inserted by pressing Option-Return or Option-Enter. In Helix, Option-Return currently does the same thing as a regular return keypress. However, Option-Enter is the Static Enter trigger, so adopting the Option key as the ‘Insert CR’ modifier would prove problematic.
In Helix 6.0 and earlier, if you are typing in a text field and you press the return key, a carriage return is inserted into the field. Pressing the enter key stores the record (or triggers the default button). In the future, when the OS no longer gives us a way to know one key from the other, pressing either key would produce the same result, either inserting a return character or entering the record. When that becomes a reality, you will have to hold down a modifier key to do one of those two actions.
Our first inclination is to make a non-modified Enter/Return enter the record and require a modifier key to insert a return character into a field. This would also address a common problem in Helix databases: most input fields are single line fields, but there is nothing to prevent a user from typing a return and continuing with more data on a second, hidden line. Many designers have built complex validations to prevent this from happening, and this change would virtually eliminate that issue.
We already have written custom code so that our next release of Helix can continue to treat the return and enter keys as distinct keys with different meanings, so this survey is really for long-term planning. The questions we want to answer are:
One way to ease the transition is that we can continue to intercept the return key as a distinct keypress (for as long as the OS allows us to) and pop up a dialog that says:
The Return key now provides the same function as the Enter key.
This dialog could also provide two buttons: Insert CR and Enter Record, with Enter Record being the default. That gives each user as much warning as they personally need while reminding them of the need to adjust their behavior. The extra step will be slightly annoying, and should encourage rapid assimilation of the new behavior. A ‘Make Enter Record the default behavior and don't show me this dialog box again!’ preference setting would allow those who get it to move on.
We could continue to support that dialog for as long as the OS provides a way to know which physical key was pressed. Cross-platform versions would have no idea about this old behavior and would treat return and enter as synonymous from day one.
This survey assesses the direction for a future release of Helix. No change will be made to the currently planned release based on this survey.
Early comments on this survey indicate a lot of confusion as to why we would make this change. Understand that the change is not because we want it. It is because one day we will have no choice.
Take a look at the keyboard picture to the right: notice the distinct "CAR RET" and "LINE FEED" keys. The linefeed character (ASCII 0x0A) no longer has its own key, its function having been absorbed as part of the return key.
In the same manner, the discreet function of the two Enter keys is in the process of melding into one. At some point keyboard manufacturers will either drop one of the keys from the layout (unlikely) or simply wire them to the same internal circuitry, making it impossible for the OS to know which one was pressed. The point of this survey is to recognize that this will happen and to find out what would best prepare Helix users for a smooth transition when it does.
For further study:
Option-Return references above changed to Modifier-Return as many good cases have been made for Shift-Return, Control-Return, etc.
In 2008, Apple began introducing keyboards without a distinct Enter key. This first appeared on MacBooks; then on the wireless keyboard designed for use with desktop computers. See this technote for more info.