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:
- Our ‘tongue in cheek’ descriptions of the options were occasionally misinterpreted as serious statements. We have nothing (well, not much) against either Bill Gates or City Hall.
- Many people missed the line above that tells you we are looking for the best way to solve a particular problem that may (or may not) present itself in the future. Those folks thought this was going to be an immediate change and it became a source of panic for them. A few, wrongly thinking we claimed this was required now, accused us of gross stupidity.
- Many people missed the fact that we may have no choice but to change the way Helix works in the future. Many people asked why we would do such a thing. The answer is found in the bullet points in the Overview section (below).
- Some people took particular offense at this survey and began a lobbying effort via public forums to rally people to vote the way they wanted the vote to go. The facts were presented in an inaccurate manner (whether intentional or not, we do not judge) and had the net effect of prejudicing people before they had a chance to read what we were really asking. We saw a marked change in the distribution of the votes between the early/late returns and those cast in the days while the lobbying effort was going on.
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.
| Enter vs. Return. What Should We Do? | < Strongly Disagree … Strongly Agree > |
| Fight The System. Never Surrender. Continue to treat the Enter and Return keys as distinct for as long as possible, no matter what it takes. Do not let Bill Gates have this victory! |
 |
| Phase It In, When Required. Give us that transitional dialog box, but not until it becomes necessary. I want return and enter to be distinct for as long as possible, but not if you have to hack the system to keep it so. |
|
| Phase It In, When Convenient. Just finish the current macOS version the way you have it now, and give us that transitional dialog box when you have time. We will deal with the change when it happens. |
|
| Phase It In, Now! Give us that transitional dialog box right away! Make sure it is in the first macOS version we see so we can train people on the new behavior right from the start. |
|
| Give In Now. Change is Inevitable. Resistance is Futile. Go ahead and make Enter and Return keys function identically now. Don’t waste anytime on that dialog box. We can teach users to press a modifier key to insert a Return when necessary. You can’t fight City Hall. |
|
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:
- What should we do when we can no longer tell which of the two keys, Enter or Return, the user pressed on the keyboard?
- How do we pro-actively work to make sure that change is not abrupt and goes as smoothly as possible?
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.
If you want to insert a literal return (CR) into a field, press Return or Enter in conjunction with a modifier key, such as Shift-Return or Control-Return.
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:
- Sun/Java bug report
- More from Sun/Java
- The NVT Keyboard
- Keycodes in the days of the early Macs
- Distinguish the two 'Enter' keys on Windows
- All sorts of keyboards
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.