Wednesday, August 22, 2012

Tab Order Change in Real Studio 2012r1

With Real Studio 2012r1 we have changed the behavior of the tab order for Cocoa apps. In the past, the tab order for controls on your window was defined by you. You would click the Edit Tab Order button in the Window Editor and set the order in which you wanted the user to tab from control to control.

There are problems with this:

1) Most applications, including the Real Studio IDE, don't have the tab order set properly. This is due to the fact that every time you add a control, the tab order must be set for that control and users (ourselves included) tend to forget to do that. This causes problems for end users and is very easy for a developer to miss.

2) On OS X, the system will handle the tab order automatically and in doing so makes all kinds of keyboard accessibility features work for free such, as being able to tab into controls in toolbars. By circumventing the system's handling of tab order, apps built with Real Studio often don't handle keyboard accessibility very well, becoming a big problem for some users that really need this. If we continue to override the OS, we can't fix the bugs with keyboard accessibility. Also, generally speaking, we try to let the OS do whatever it does naturally so that we don't introduce bugs by circumventing it.

We have discovered that most applications have a tab order that is the same as what the OS would normally provide. So for Cocoa apps built with 2012r1, the tab order set on the layout is ignored and the tab order is generated automatically so that the OS can handle it. This solves both the problems above.

Currently, this change in behavior is limited to Cocoa apps. But it is our intention to change it for Windows, Linux and web applications as well. If you have a special case where you need the tab order to be different than the default, there is a way to handle this:

Tab order is handled by the parent container. You can use a parent control such as a group box or canvas to change the tab order. For example, say you have four Textfields, two columns and two rows:

C1R1 C2R1
C1R2 C2R2

Normally, the tab order would go:

C1R1 -> C2R1 -> C1R2 -> C2R2

If you need to change the order so that, for example, it goes C1R1 -> C1R2 -> C2R1 -> C2R2, put C1R1 and C1R2 on a canvas control. That will cause the tab order to go down instead of across.

We believe this change will result in a better user experience because the tab order will automatically work as expected on that OS, while still leaving you a way to achieve a different tab order if needed. If this method of changing the tab order does not work for you, please contact us through tech support. Before we make this change permanent, we want to get input from you, the community.

UPDATE: After considering feedback from the community, we have decided to rollback this change in R1. We are working on an update (R1.1) that will re-enable the ability to set the tab order once again. We have found a way to provide the default tab order along with a custom tab order option (the one you have now) which we will add to a future version.


Oliver Osswald said...

Using a parentcontrol in order to get away from the automatic taborder does not work for me. I'm using a pagepanel, and controls are created on the fly onto it. I did a screenrecording earlier on, which shows how the input cursor jumps around: no meaningful taborder whatsoever.
I would prefer to keep things as they were before, because my software for seminar management depends on the possibility to create individual input screens for every client, for every training organizer.
Said that, I can work around this new "feature" as long as the keydown event for every control is working. Of course it means a lot of additional, unexcpected work for me (I guess you are going to eliminate the tabindex property), but at least I have a perspective for a workaround).
I'm not happy about this change.

Jim said...

I completely disagree! EVERY language, for a GUI environment, I've programmed in has a TAB ORDER property for screen objects. I can't ever think of a case where the OS should change the designed layout and it is a good thing. Tab order, especially for data entry programs, is VERY IMPORTANT. I'm not familiar with the "keyboard" issues on OS X that you "can't fix" if you don't throw out the baby with the bath water. This seems like an INSANE solution.

Paul Sondervan said...

I'm the programmer, I'm the owner of the programs that I make.
Therefore I decide what the tab order should be, not the OS I'm using.
Sorry, Real Software, but this is a not a good idea!
You can let it default work the way you changed it in 2012r1, but at least give us the freedom of setting the tab order the way we want it to be.

Dale Arends said...

I, too, vote against this change. By giving us, the programmers, the means to set the tab order to the way we need it, it is our fault if it isn't right in the applications we (or you) turn out.

The tab order isn't broken; don't "fix" it.

Henrik Ingvarsson said...

I use Real Studio mainly because it allows me to design a program that behaves in an similar way, independent of the OS the user is currently running. I would very much like to keep it that way.

I agree with Dale Arends, there is no need to fix what is not broken.

Geoff Perlman said...

Thanks for your feedback everyone. Based on the use cases you provided, we are going to roll back this change so that it will work the way it always has been. We have come up with a solution for a future release where the user will be able to choose between automatic tab order (as described in the blog) and custom tab order (as you are used to doing today). That will provide the best of both worlds. There will automatically be a sensible tab order that will work in most cases but when it doesn't, you will be able to provide a custom tab order just as you do today.

Oliver Osswald said...

I'm thankful for this decision. And I'm impressed. I don't know of any other company with this quality of communication, where the company gives the possibility to their clients to discuss decisions - and where one can experience that the company is listening to customers. And then decisions are made, without further endless discussions. Despite some frustrations throughout the past 4 years, this is one of the reasons why I am a Real Software fan. Thanks!

Julian Mussi said...

Geoff, Thanks for listening to the feedback and rolling back this change. I do like the option of having tab's set automatically. There are cases where this will be a "feature" but I know for me there are enough exceptions, where I need to manually set tab order, that the change would have been a step backwards.

Ruy said...
This comment has been removed by the author.
Ruy said...

I'm very disappointed with Real Studio. Performance is slower on Linux than on other operating systems. I have the professional version and the software freezes for a while when I click right (context menu).

Paul Sondervan said...

Thank you Geoff.
The solution you're going to provide in the future is exactly what I was hoping for.

Produino (swort) said...

This would only be good if it's implemented VERY well. But i doubt that will be the case. As many devs need differend apps...

Anonymous said...

My 2c worth. Letting the OS dictate how an application's tab order works (even with custom tab order retained in next release) is NOT what I want. The bizarre differences (tab to radio/checkbox/button on Windows, but not on Mac...etc) is a nuisance. We design apps to work a particular way, and we like that the app works the same on all platforms. To rectify this we've had to develop a new UI framework that replicates much of what a window should (IMHO) already do for me (but doesn't), like real data-aware controls and control over TAB keypresses (due to the "triple-firing" of LostFocus events when TAB is pressed in 2012R1 has led (forced) me to control TAB order directly (ignoring Real's custom tab-ordering and crazy "OS default" tab ordering).