Tuesday, April 30, 2013

Why native controls are important

9to5Mac is reporting that iOS 7 will sport a new user interface. It's said to be flatter and simpler. If this is true, it almost certainly means that controls will have a new look as well. This reminds me of when Apple shipped Mac OS X with its new Aqua interface. Every version of Windows has redefined the look and feel of most of the user interface. Ubuntu continues to improve the user interface of the popular Linux distro as well.

For some software developers, a change in the OS user interface is a problem. They are using a development tool that draws controls itself rather than going the extra mile required to use native controls. Native controls are drawn by the OS, not the application. When the app is moved from one OS to another (for example between iOS 6 and iOS 7 or between Windows XP and Windows 7), it takes on the native user interface because it's using native controls. Apps made with development tools that draw their own controls suddenly look out of place and strange.

This is why Real Studio has always used native controls ever since it was introduced in 1998. We want our user's applications to have a user interface that matches the OS. Most iOS development tools don't make the effort to use native controls. We do. We previewed our iOS development efforts at our annual user conference last week. We use all native controls for iOS because that's the level of effort our users have come to expect from us.


Unknown said...

Since native looks differ between platforms It could be useful if a future layout editor could be used to edit
dialog/window/screen layouts for ALL platforms, and be able to switch between an iOS look to a Windows or Metro look.

The metadata would be stored in one place, with all variants of control placing, size , colour etc recorded.

A little like "layers" in some drawing programs.

Unknown said...

This needs to be able to let one edit a Windows "look" from within a Mac OSX version of RS.

Very hard naturally - since it would need RS to come up with their own code to "paint" equivalents of how the controls actualy look on the other platform. But once
implemented would be a huge time saver.

Geoff Perlman said...

This would be interesting but I question how useful it would be since your app can run on many different OSs. We would have to mimic each one's UI which would be a lot of work. With remote debugging, you can quickly run your app on each OS to see that it looks appropriate and functions correctly.

Eliott said...

Quote: "This is why Real Studio has always used native controls ever since it was introduced in 1998."

This is not true for one of the most important controls: the Listbox. And it is more and more a problem to explain to Mac OS X users, why lists in my application are noticeable behaving (and also looking) differently as other applications.

Anonymous said...

I hope You include

- A good Data Grid control
- A good Chart control

with Xojo. I'm frustrated to rely on expensive third part controls.

It's a must if You want developers to see Xojo as a professional developing tool.

At the same time I think it's a must to follow the Recognition rule. End users will be more productive when new tools arrive that follow the de facto standard on each platform. That is for Windows and Mac while it's not a must on the Linux desktop.

Kind regards.

Geoff Perlman said...

@ Elliott - When Real Studio started out, the listbox control was not native on ANY platform. If you wanted one, you had to implement it yourself. Now that all platforms have a native listbox implementation, we plan to add on based on that. However, even our listbox uses the OS drawing routines to draw the headers, it uses the system font, it uses native scrollbars, etc. So it's built from native OS calls.

Unknown said...

Geoff, not sure thats accurate. I was a Windows SDK and OS/2 developer back in the early 90's, and the ListBox was a standard part of the CUA tookkit.

Maybe you're referring to the Mac? I know that Windows and OS/2 has always had a listbox.

Unknown said...

But in some cases the native controls are useless. On Windows the TabPanel control is a flickering nightmare when you move your mouse over it. And to top it off, it is butt-ugly, just some square tabs with little control over how they look. Futhermore, the control has a bug in it that doesn't handle tranparency properly in the built executable but looks correct in the IDE, feedback #14816, (and as I later found out from the RS support staff it is paired with a non-native, canvas-based control that is used while in the IDE). Now how do you properly code around that? So, I am all for using native controls if it is a viable option, but in some cases it just isn't and there is just no remedy. At this point you asking why you didn't do it yourself with a canvas-based control.

Anonymous said...

I simply wouldn't use Real Studio if it didn't have native controls. There are some decent products that compete with Real Studio but I just can't even consider them if they don't use native controls, it's hugely important and it's why I continue to give my money to Real Software.

Having said that, platforms move on and there are a number of controls and similar items that Real Studio doesn't support without using declares.

Anonymous said...

If the Windows controls are native how come that there's a border around PushButtons when on a coloured background? How come that the background of radio and checkboxes are not transparent?
I can do all of this in Microsoft and Delphi tools on Windows without any problems.

William@Real said...

@msa: A native Win32 RadioButton or Checkbox is not transparent, but you can set its background color. There's no feature in Real Studio to do this, but one trick is to place them over a colored Rectangle control, it will inherit its background color. Other common UI Frameworks are WinForms/.NET and WPF/.NET. I believe WinForms/.NET RadioButtons and Checkboxes also have this problem but again you can set its background color. As for WPF/.NET they could be transparent since their UI is all drawn (not a native Win32 control). It's harder and harder to distinguish nowadays what is a truly native control on Windows, do they mean Win32 or WPF? If you take a look at MS products like MS Office or Visual Studio you'll notice that most of their UI is custom. The only really native Win32 experience left is Notepad and a handful of control panel dialogs. Notice the difference between a truly native Win32 menu (i.e. Notepad or Real Studio) vs. custom like Explorer, Visual Studio, etc.