KSP user interface design choices.

[Galane]

Is it Unity or just KSP that is using what looks like a "radio button" for checkboxes?

It's a decades long tradition in GUIs to have round spots with a dot, only one of which in a group may be selected. They're called "radio buttons" after the old car radio preset buttons where when you pushed in one to change to the station it's set to, any other button that was pushed in pops out.

Checkboxes are square or square-ish and use either an X or check-mark to denote they've been selected, and any or all of them in a group may be selected.

However, some programmers have at various times figured out how to use radio buttons like check boxes and check boxes like radio buttons, either by hacking the programming environment they're using, or simply ignoring the instructions, or by using custom graphics to subvert the design convention that *everyone knows how to use*. Even worse is when a program makes no visual distinction between radio buttons and checkboxes, or uses a singular radio button which when selected cannot be *unselected* except by exiting or canceling the dialog box. If there's only *one* on/off choice use a checkbox. The Ascent Path Editor is using a checkbox, though graphically distorted into a sort of mashup of a checkbox and radio button.

Why go to so much extra effort to confuse people about how the user interface for your software works? The base concept of the GUI was to have *common* functions across various programs look and function the same, the goal being to make it easier to learn multiple programs because once a user learns the UI functions, those things are already known for any new program. Unless the program authors think they have a 'better way' and decide to not follow the convention.

An excellent resource on UI design is this older copy of Apple's Human Interface Guidelines (from before they decided to toss it all with the horrible UI of Quicktime, followed by other screwups in early OS X versions).

http://interface.free.fr/Archives/Apple_HIGuidelines.pdf

Another common problem in KSP is buttons that toggle a state yet do not indicate the state. One example is Control From Here. Click that all you want, you get *no indication* that it has actually done anything - unless the orientation of the control part you have changed to is different from the one changed from AND if you have the navball visible. The navball rotation will change. What should happen is the Control From Here buttons should toggle, staying depressed on the part that has control - or an indicator next to the button should appear. Anything to show on the right click menu that a part does or does not have control without having to click the button to be certain the part you want to have control actually does.

[Guest]

Unity not us.

As far as I know, that is. My experience with the GUI would lead me to believe it is very simple and doesn't have a dedicated checkbox widget, the radio button is overloaded.

[Murph]

An excellent resource on UI design is this older copy of Apple's Human Interface Guidelines (from before they decided to toss it all with the horrible UI of Quicktime, followed by other screwups in early OS X versions).

http://interface.free.fr/Archives/Apple_HIGuidelines.pdf

Apple used to be one of the best for it. In recent years, they have fallen considerably, and are now making some terrible mistakes, like removing the page title from the web browser by default, hiding the page URL by default, and when you turn either of them back on it's in a way that you can't see more than a fraction of the full title or URL. It's so that there's more space on screen for content, or something, but being done on the Mac platform which ships with some of the physically largest and highest res screens in the industry! Some blithering idiot inside Apple took the decision that because they want to have a more unified feel between the iPhone, iPad, and iMac, Safari on the Mac had to be crippled in breathtakingly stupid ways, completely missing the point that a huge proportion of customers on the Mac platform are what they would call "Pro" users, who want the full information, not some dumbed down tablet app on a big screen.

On topic, officially confirmed by Squad in the dev notes is that the current UI will be completely gone with the next release, if all goes to plan. Unity 5 is forcing them to redo the UI.

[basic.syntax]

a huge proportion of customers on the Mac Windows 8 platform are what they would call "Pro" users, who want the full information, not some dumbed down tablet app on a big screen.

Fixed, lol. Windows touch-centric Start Screen, leaving behind the higher information density Start Menu design. Everybody's trying to shield users from detail and complexity these days.

[Tw1]

Another common problem in KSP is buttons that toggle a state yet do not indicate the state. One example is Control From Here. Click that all you want, you get *no indication* that it has actually done anything - unless the orientation of the control part you have changed to is different from the one changed from AND if you have the navball visible. The navball rotation will change. What should happen is the Control From Here buttons should toggle, staying depressed on the part that has control - or an indicator next to the button should appear. Anything to show on the right click menu that a part does or does not have control without having to click the button to be certain the part you want to have control actually does.

That's odd, I'm sure I can recall some buttons in KSP that did do this...They'd stay 'pressed' when active. Maybe they where part of a mod.

This is a good point though. Some other parts do show their state in the words next to the buttons. Perhaps the part you're controlling from could show 'active control point' next to the button.

[sedativechunk]

OP,

First of all, I am a web developer and often do UI interfaces. Thank you for posting that very interesting Apple Guidelines article, I have saved that PDF to my PC for future reading. Very interesting read on user interfaces. It looks dated but still practical for today.

Secondly, I happen to be a Unity developer myself, well used to be anyway. At the time KSP came out, I may be mistaken, but the early versions of Unity did not have many "assets" available for creating simple user interfaces, eg. checkboxes, radio buttons, and etc. These features were added on later as assets. If I'm not mistaken, they significantly improved that area over the years.

Also, speaking as someone who has done tons of game programming in the past, creating UI's for video games is VERY complicated. At the core, you want to make a fun and exciting video game and make the gameplay most important. Often times when doing that, it is easy to skip or overlook the UI. In KSP's case, I feel this is probably what happened. They focused on gameplay more than interface, which is a good thing. The game does have a rather clunky interface and is difficult to understand for newcomers. M

Making UI features is complicated and time consuming, especially things like buttons. You have to literally program every aspect of it, the up and hover positions, a click position when clicked if wanted, attach sound effects, and then even have it scale appropriately when the screen is different sizes. They are a HUGE pain in the rear end to do correctly. One of the hardest things to create are health bars. Health bars are the absolute hardest to program. Resizing sprites/textures as health goes down. Personally I think one of the video games that has the best UI's out there is Diablo III. Yes, a commercial game, but I hugely compliment blizzard on the interface of that game. It is one of the best ever created IMO.

[Galane]

That Apple document predates OS X, it also predates Quicktime 4, which heralded Apple's abandonment of much of the standard conventions and ease of use conventions they played a major part in defining.

I've used and worked on and fixed computers since 1983, so I've experienced the full range from command line to various ANSI and graphical shells and the various Windows and Mac versions plus some others. In that time I've run into a lot of flat out stupid and WTFH things. (My first hard drive was five megabytes and installing MS-DOS and all the software I had filled up half of it! Today I routinely work with single files larger than 5 meg.)

A very common thing that time and effort get wasted on are custom dialog boxes, especially for opening and saving files. The operating system GUI should provide just about every common dialog box (that's why they're called common) any program will require - yet programmers persist in coding as if they're writing a DOS program that had to do *everything* with its own code.

Ironically, some of the worst at not using the built in stuff provided to make creating a program easier are Microsoft and Apple.

As for the "Modern" Start Screen in Windows 8.x and the UI of current Windows Phone, it's a throwback to Windows 1.0. What's so similar? They both have non-overlapping tiles with active content. Win 8 has higher resolution and can display more colors and more tiles, but the overall UI has reverted to the square corners, flat and saturated colors and zero "3D" effect of Windows 1.0 through 3.0. The adverts for Windows phone show tiles with a heavy use of Cyan, White, Magenta and Black - the exact colors as the default palette of a CGA video card. Rotate a WinPhone 90 degrees clockwise so the bar up the right side is along the bottom and it's even more like Windows 1.0 with its command line across the bottom.

The only piece of design style not harking back to Win 1.0 are the square cornered buttons. Win 1.0 had round cornered buttons and a heavy outline line indicating which button Enter would activate - almost a pixel perfect copy from Macintosh. After the lawsuit, Windows had no round corners anywhere and the indicator line became a thin dotted one. We've come a long way for Microsoft to copy the style of a GUI they made 30 years ago, that failed to set the computing world on fire.

I wonder how hard it'd be to create a GUI for Windows 1.0 mimicking the style of Win 8.x's Modern screen, and have it run in a virtual machine with the ability to run in higher resolution with more colors? Call it Windows -21.9 (8.1 minus 30)

Edited May 20, 2015 by Galane

[sal_vager]

Radio buttons do seem common, though they may not always be called that, for example the Godot engine has one node called ButtonGroup that only allows one child button to be in a pressed state.

"Yay, a radio button" you might say, but sedativechunk is right, everything has to be set including the unpressed state otherwise even when not pressed, the button won't turn off whatever it activated, so just having that "radio button" ability is not enough on its own.

[Diazo]

That's odd, I'm sure I can recall some buttons in KSP that did do this...They'd stay 'pressed' when active. Maybe they where part of a mod.

This is a good point though. Some other parts do show their state in the words next to the buttons. Perhaps the part you're controlling from could show 'active control point' next to the button.

You are partially correct. If the value a button in the right-click part menu is attached to a true/false value, then it does stay pressed in when activated.

However, the Control From Here button is attached to a script that runs every time you click it, therefore it is always "not-pressed" no matter what else happens.

D.