totm august 2019 Experiment on a possible Tweakables Redesign (Result)

[beik]

Disclaimer: Hey devs, don't take this as criticism. I know how regular people usually are clueless about how complex things are beyond the surface of a development process... This is just for fun, peace ✌️

Hello folks!

I work as a full-time UI/UX designer, and something that grinds my gears is how a super complex game as Kerbal Space Program lacks a good interaction design foundation in some parts. I'm always worried about how hard is the learning curve for newbies... To understand how basic things work.

 

So, I decided to give a little bit of love back to the community by doing some design experiments. I hope this gets people inspired somehow.

---


Experiment on a possible Tweakables Redesign

1. Analysis

Ok, so this tweakable popover looks too complex for a basic part. I start by analyzing the content, trying to understand the patterns behind.

I added a color-coded interpretation on how most of the content relationship, so I could compare with other screens.  

 

Using Advanced Tweakables sounds unfair, so let's get it going without it. I will miss you Autostrut. The screens stills look complex, with a loose relationship between the content.

The main thing that draws my attention are:

• Lack of order and relationship
• Inconsistent readouts
• Different kind of controls look like the same button
• Parameters (input) and Resources (output) looks too similar
• "#" have a loose mapping to the Parameters input
• "Crew report" generates science, but it doesn't stand out from secondary stuff.

 

This is a "cold" analysis that I'm doing without a proper user research process. To do it for real, the right way would be doing some usability tests and card sorting with real people. If you are short on time, the best way to start studying a user interface is by these two points of views:

10 Usability Heuristics for User Interface Design
https://www.nngroup.com/articles/ten-usability-heuristics/

Understanding mental and conceptual models in product design
https://uxdesign.cc/understanding-mental-and-conceptual-models-in-product-design-7d69de3cae26

Alright, let's see what else I can collect...

Comparing some basic tweakables side-by-side opened my mind that the "real" problem in the pods is how they fail to communicate the different modules bundled in a single part. Most of the smaller tweakables are pretty straightforward to understand, even with some features that feels they slipped through Advanced Tweakables and ended in the stock mode.

This a non-extensive list of the inputs/outputs, so I can have a clear picture of the main UI patterns.

 

 

2. Process

I decided to use the Mk1-3 Command Pod as a reference. It's fairly complex and it covers a god range input/outputs.

I start from a basic wireframe (to focus on the content) and then move my way up adding more structure...

In the end, I decided to not use the "collapsible category" idea because of the amount of visual noise it introduced and rollbacked some of the ideas because the original ones seem better.

 

 

3. Result

This looks like the first steps of a draft for a UI library. It was way harder than I expected to give proper feedback/affordability to the buttons. The main idea is that the user can figure it out what kind of button it is before clicking it.

 

 

 

What do you think? My favorite parts are the science indicator and divisors

 

Source file: https://www.figma.com/file/09xWDTa5XQJy140q7sCyPX/Kerbak-–-Tweakables-Redesign?node-id=0%3A1

Edited July 24, 2019 by beik

[Rocket In My Pocket]

If it was a mod, I'd use it.

[CobaltWolf]

I love it!

[MK3424]

If only this was a option as a UI in the stock game!

[Zorg]

Wow that looks fantastic. So much more readable. I hope someone at Squad sees this and takes some lessons on board.

[KerboNerd]

SKWOD WHERE U AT

[Stevphfeniey]

Hi,

Please release this excrements as a mod as quickly as possible. I have a mighty need!

[Space_nico]

Give to that Kerbal a lot of funds! ♥

UI like we love them! :3

[Shadowmage]

8 hours ago, beik said:

What do you think?

I like the overall concept behind it.

 

Design-wise -- I love it.  Excellent work, and would love to see KSP adopt even just the styling differences to the controls you've outlined (e.g. boolean button vs. instant-action-button vs. open-a-window-button).  Easily distinguishable information sliders (resources) vs. controllable sliders, and general much cleaner look to all the controls.

 

Implementation-wise -- things get tricky.  Such as how to apply it in a generic/automated fashion?  We don't have a UI/UX expert that can come and re-arrange the UI for every individual part, so there needs to be some manner to specify the layout/grouping of controls in the configuration files, or preferably entirely automatically (I know, dreaming...).

And it all has to work with mods, and the new features that they add.  Those 'new features' from mods need to somehow automatically create new groupings, and have their relevant controls grouped intelligently.

Edit:  Separate feedback on design concerns from implementation concerns.

 

Edited July 24, 2019 by Shadowmage

[beik]

1 hour ago, Shadowmage said:

I like the overall concept behind it.

 

Design-wise -- I love it.  Excellent work, and would love to see KSP adopt even just the styling differences to the controls you've outlined (e.g. boolean button vs. instant-action-button vs. open-a-window-button).  Easily distinguishable information sliders (resources) vs. controllable sliders, and general much cleaner look to all the controls.

 

Implementation-wise -- things get tricky.  Such as how to apply it in a generic/automated fashion?  We don't have a UI/UX expert that can come and re-arrange the UI for every individual part, so there needs to be some manner to specify the layout/grouping of controls in the configuration files, or preferably entirely automatically (I know, dreaming...).

And it all has to work with mods, and the new features that they add.  Those 'new features' from mods need to somehow automatically create new groupings, and have their relevant controls grouped intelligently.

Edit:  Separate feedback on design concerns from implementation concerns.

 

 

You nailed the spot with "how to apply it in a generic/automated fashion". The natural answer is smart defaults and automatic grouping by module (on complex tweakables). I don't have any knowledge of the GUI API, so my assumptions are based on previous challenges that I had.

Most of the tech teams around the world don't have a UX expert all the time, so they fix this by creating UI Guidelines and Design principles. This is usually a documentation made together with the devs, so they can have more autonomy to make decisions by their own . In KSP specific case, the best approach would be to tackle all stock combined parts (mostly Command parts) and extend the GUI options that we already have. By extending (and not enforcing), changes can be made in a progressive fashion, and we can always degrade/fallback to the existing solution. What you said with "needs to be some manner to specify the layout/grouping of controls in the configuration files" is what I have in my mind with "extending".

Thanks for the awesome feedback

---

For people asking to add it as a mod, unfortunately I'm on the side of the table that complain about the typography, not who push codes (AKA lack of dev skills).
I will see if I can help other modders!

Thank you guys for the warm response <3

[Poodmund]

@James Kerman this thread deserves a Thread of the Month nomination for sure!

[blowfish]

Fun fact, the part action window already sort of has support for collapsible groups

It doesn't look the best.  And nothing uses them anyway.

Edited July 25, 2019 by blowfish

[Poodmund]

Can you only list strings and values in those drop downs or can you insert more submodules within them?

On 7/24/2019 at 8:21 AM, beik said:

Disclaimer: Hey devs, don't take this as criticism. I know how regular people usually are clueless about how complex things are beyond the surface of a development process... This is just for fun, peace ✌️

Also, this certainly should be taken as criticism. Criticism is very helpful when as constructive and we'll presented as this with a good amount of analytical thought on the issue.

[Mignear]

Pretty good.

Something I'd add is colored buttons, for things that are toggled on/off, you could have green and red for the button.

[Blaarkies]

59 minutes ago, Mignear said:

Something I'd add is colored buttons, for things that are toggled on/off, you could have green and red for the button.

Careful with that, it strays close to the current problem we have with the "Partial Transmission" button on comms dishes. It says the text "partial" next to the button, which of the following is correct?

• it is in partial mode right now, and clicking the button changes it
• it is in the other mode, but clicking the button will activate the "Partial Transmission" mode

The darker pressed in buttons are really good at showing, "This label is now active"
I know we don't get confused by that (we understand rocket science after all), but that is what the UX books say

Edited July 25, 2019 by Blaarkies

[beik]

8 hours ago, blowfish said:

Fun fact, the part action window already sort of has support for collapsible groups

It doesn't look the best.  And nothing uses them anyway.

Wow, this could be really helpful! We should definitely use this to hide info/actions that are too specific for a particular context. 

 

8 hours ago, Poodmund said:

Can you only list strings and values in those drop downs or can you insert more submodules within them?

Also, this certainly should be taken as criticism. Criticism is very helpful when as constructive and we'll presented as this with a good amount of analytical thought on the issue.

Had the exactly same doubt about submodules in the collapsible groups

About the "criticism", you are right! I like to always add this disclaimer to be respectful with other people work. Making things right is always harder than it seem.

 

3 hours ago, Blaarkies said:

Careful with that, it strays close to the current problem we have with the "Partial Transmission" button on comms dishes. It says the text "partial" next to the button, which of the following is correct?

• it is in partial mode right now, and clicking the button changes it
• it is in the other mode, but clicking the button will activate the "Partial Transmission" mode

The darker pressed in buttons are really good at showing, "This label is now active"
I know we don't get confused by that (we understand rocket science after all), but that is what the UX books say

Having a good guideline would be a good start. Without a extensive research I found:

• [  ] RCS – Text remains the same, state is visible by the button pressed fx and on a separated text aligned to the right
• [  ] Lights On – Tells the events that is going to happen (by displaying state goal, and flip it after the event)
• [  ] Partial Transmission – The text IS the state. Clicking it just flip

Maybe there's a need for strict boolean that keep always the same text and a boolean that expose the state in the text, but the "Lights On" vs. "Partial Transmission" is hard to justify.

Fun fact, I actually made it wrong in my design above. The little green light in the boolean control should be ON in the pressed state. oops!

 

Edited July 25, 2019 by beik

[Shadowmage]

8 hours ago, blowfish said:

It doesn't look the best.  And nothing uses them anyway.

Interesting -- have any further info on that feature / use?  I have a few PartModules that could use cleanup like that (mostly KSPWheel data displays)

[KerbalKore]

Holy crap I need this.

[Guest]

This is terrific. SQUAD has been known to pick up things like this, I hope they do on this one. KSP has grown a lot of hair over the years and it needs a brushing.

[blowfish]

2 hours ago, Shadowmage said:

Interesting -- have any further info on that feature / use?  I have a few PartModules that could use cleanup like that (mostly KSPWheel data displays)

KSPField has the fields groupName, groupDisplayName, and groupStartCollapsed (default false).  Any fields with the same groupName will end up in the same group, I think for the second two you would only need to specify on the first field (doesn't hurt to specify on all of them of course).

[CaveJohnson376]

On 7/24/2019 at 8:22 PM, Shadowmage said:

Implementation-wise -- things get tricky.  Such as how to apply it in a generic/automated fashion?  We don't have a UI/UX expert that can come and re-arrange the UI for every individual part, so there needs to be some manner to specify the layout/grouping of controls in the configuration files, or preferably entirely automatically (I know, dreaming...).

 

As starting game developer, i can say that this cant be tricky or hard (not for me and coding, of course ), all that seems simple. Just set module readout/input type in part config as specific category type, make categories and modules sorting rules and here we go!

P.S. Congrats on thread of the month! You done really cool work!

Edited August 1, 2019 by CaveJohnson376

[blowfish]

5 hours ago, CaveJohnson376 said:

As starting game developer, i can say that this cant be tricky or hard (not for me and coding, of course ), all that seems simple. Just set module readout/input type in part config as specific category type, make categories and modules sorting rules and here we go!

The realm of what's simple in game design in general and what's possible to change in KSP by modders are very different things.  As a game developer you generally have access to change all of the game's code as well as things like UI prefabs.  In KSP modding that isn't the case.  We get a very limited window into KSP and what it's doing.  So there is no "just do" any of those things

[CaveJohnson376]

1 hour ago, blowfish said:

The realm of what's simple in game design in general and what's possible to change in KSP by modders are very different things.  As a game developer you generally have access to change all of the game's code as well as things like UI prefabs.  In KSP modding that isn't the case.  We get a very limited window into KSP and what it's doing.  So there is no "just do" any of those things

I understand that
This forum is for suggestions and this topic is about PAW improvement suggestion, and i just suggested the way to implement suggestion we're talking about. To KSP devs, of course

[Wjolcz]

Looks really good!

[Enceos]

The PAWs of the proposed UI look very good on dark background. How will they look above textures of poles or deserts?

P.S. There was one attempt at UI overhaul previously, which proved the concept.

Kerbalism uses its own UI, which also has a very contemporary look to it.