You can’t spell User Interface without U & I

[Vortygont]

I would like to see in UI more orbital parameters, like period, inclination, eccentricity, mean anomaly and etc

[Sade]

Can't wait for 0.2.1, I had fun with 0.2.0 but now the bugs have gotten too frustrating.

[karstux]

Can we have (permanent) altitude numbers on the AP and PE nodes? Planning re-entry trajectories is really tedious - adjust, click PE node to check, adjust, click, repeat ad nauseam... 

[phuzz]

One minor issue I've not seen mentioned yet: Renaming vessels.

It took me a while to find out that I could rename vessels via the tracking station (renaming them on the fly via the command pod in KSP1 was handy too), but that's a discoverability issue.

The main problem I had was the colour of the text, and the colour of the background when renaming a craft were so similar I couldn't really read what I was typing. (I'm very slightly colourblind, but it's almost never an issue form me in games). Just picking a more different colour for the background would really help here.

 

Re the Part Manager. Like most KSP1 players, I do miss being able to just click on a part in the VAB/in flight and alter just the options for that part. I also miss being able to pin the windows for certain parts on the UI for easy access. That said, the Parts Manager does have a use when there's a part buried deep inside my craft, and there's no easy way to click on it (especially if my craft is rotating etc.), so the PPart Manager does make it easier to just drill down the list to find what I need and change it's settings.

[RichByName]

A lot of welcome improvements flagged here.

Precision maneuvering is an absolute must so will be very welcome.

Only 1 million more to go!

[Autismus Maximus]

8 hours ago, RocketBlam said:

I'd like to vote here for "Pause" NOT being the lowest level of warp. 1X should be the lowest, and pause should be separate.

Yes please 

 

https://imgur.com/VVT9s3y

[alexyogurt]

 pls move navball to center where it belongs my eyes hurt from having to stare at the corner and then dart all the way to the right to see my remaining dV when I'm launching

[ncw33]

5 hours ago, HebaruSan said:

Supposedly there is a "UI/UX team", but they can't figure out very basic, glaringly obvious ideas like this (which I personally implemented in a KSP1 mod reflexively as soon as I realized I needed to display pending timespans—in fact you can see it in my many-years-old forum signature!) without user feedback? It's frustrating and begs for an explanation.

Come on, give them a break @HebaruSan.

Here's your explanation: they're unlikely to be lazy, they're clearly not stupid, so presumably they're busy or distracted, maybe on the mountain of work for Colonies.

Little bits of polish take time - especially when it's the entire game that needs polish, not just one small mod.

Don't say they're "supposedly a UI/UX team".

[Kimera Industries]

11 hours ago, Pthigrivi said:

Love all this. I have made a number of UI notes but I want to speak to a very specific important function that I think neither KSP1 nor KSP2 has really captured: Snapping maneuver nodes to Ap, Pe, An, and Dn. 90% of the time when traversing space you're really trying to align your burn vector with one of these 4 points and it would be absolutely amazing if we could right-click and have the option to snap a maneuver node precisely on them. This is a little tricky now because of the way KSP2 handles burn start/stop times vs KSP1's centered nodes, but it would be SO valuable to have this capability for accurate and efficient maneuver planning and execution.  I think this is one of those little tools that if implemented folks would wonder how they ever got by without it. 

Amen to this. It's a great idea.

[AtomicTech]

16 hours ago, Nesses said:

Greetings, forum-goers! I’m Ness, the Art Director here at Intercept, and I’m interrupting your regularly scheduled UpNate to bring you a special broadcast. Let’s talk about KSP2’s User Interface, the most meta of all game art disciplines! 

UI must surface moment-to-moment information and actions to players in either text or clever visual shorthand. When making a simulation game like KSP, an even greater burden of information is placed on the UI, since we need to supply players with a mountain of information and choices without overwhelming either the player or their screen’s real estate. It’s a fascinating and sometimes frustrating balance to strike and I am consistently impressed by our UI/UX team’s ability to analyze abstract, un-implemented features and translate them into visuals. Jordan and Colton from our UI/UX team at Intercept work tirelessly to make rocket science digestible and slick-looking!   

Before we dive into future plans for KSP2’s UI, I’d like to first take a quick look at KSP1’s. Its UI went through several distinct stages over the course of KSP1’s history, the most radical changes happening early in development. One thing that I love about videogame UI is that on top of all the information it must convey, it’s visual styling can suggest subtle narrative and worldbuilding—something that KSP1 has absolutely utilized and that we will continue to evolve in KSP2. 

Some very early unreleased examples of KSP1 0.2’s UI can be found on HarvesteR’s dev blog. We can see a mix of fonts, both handwritten and geometric sans serif, as well as a barebones parts catalogue. The mix of fonts here is the most interesting detail to me; the handwritten altitude and speed readouts suggests a theme of "DIY" that applied to both the Kerbals in the game and the developers making the game. 

A later iteration of the UI around KSP1 0.3 introduces the familiar grey that stuck around for the rest of development, as well as a precariously-stacked flight heads up display. This cobbled-together “junkyard” readout was an evolution of the Kerbal narrative of a DIY space program using salvaged parts.

By the time KSP1 0.7.3’s public release rolled around, the staging stack had moved to the left side of the screen, we had a flight cluster, and Kerbal live-feed portraits all carefully spaced around the edges and wrapped in that grey pseudo-metal that we saw back in 0.3. Gone was the junkyard aesthetic, and the skeuomorphic gauges were carefully lined up.

Ty to @Whirligig Girl for the image above

And finally, a shot of KSP1’s UI as of 1.0 

We’re all familiar with the symbiotic effect that mods had on KSP1, and I believe that by keeping the UI simple and grey, it allowed modders with limited artistic ability to easily match the look of the canonical UI and maintain a level of visual consistency which ultimately cuts down on cognitive load and increases immersion. This is absolutely something we on the art team are aware of in KSP2, and when it comes time to roll out additional modding tools the UI team will also share our internal style guide for modders interested in mimicking KSP2’s UI.

Now onto what I think most of you all are here for; what’s in store for the future of KSP2’s UI now that For Science! is out the door. In the weeks since release, we’ve enjoyed following along as new and returning KSP2 players have checked out the missions, discovered points of interest, and put all of our flight systems through their paces. As thrilling and satisfying as it’s been to see all of the impressive feats you’ve achieved since the For Science! update, we’re also been watching and documenting your reactions to the user experience and the user interface in particular.

We’re excited to see that many elements of our UI have facilitated a smoother first-time user experience, but with your help we’ve also identified several areas of confusion that we are actively tracking. These improvements include:

• Fonts can be hard to read for a variety of reasons (size, scaling, color, contrast, etc.)
• The maneuver gizmo can be difficult to interact with, and precision maneuvers are especially difficult
• Trajectory tag markers can be difficult to differentiate or identify
•  Trajectory tag stems can get tangled with one another in ways that cause significant visual confusion
•  SOI transit "bullseye" indicators are too bright, too big, and too prominent relative to other map elements (this is a personal bugbear of mine)
•  Rearranging the staging stack order when selecting the bottom-most stage is difficult
• The Part Manager presents several usability issues including but not limited to; observing many parts at once, using the Resource Manager as a separate app to specifically track fuel on a per-part basis feels awkward, associating a viewed part in the manager with the actual part on the ship
• We are not adequately communicating that "Revert to VAB" causes a loss of recent progress, and there are situations when reversion should not be accessible at all
•  It is not obviously clear, especially to new players, when a vehicle is recoverable
•  The audio-only countdown on launch presents both accessibility and legibility problems 
•  When in any time warp state other than 1x, the UI does not adequately communicate the state change. The tendency to interpret an under-warp failed control input as a bug has caught out quite a few members of our own team, and is likely responsible for quite a few bug reports
•  Visual styling for some UI elements is not completely unified 
•  It would be very handy to be able to see mission requirements in the VAB while constructing a vehicle

KSP2’s Early Access is delivering exactly the kind of active feedback loop we were hoping to see, and we’ve now got a nice collection of feedback items to help guide our work priorities. We’re excited to continue improving on the UI. In the meantime, we’ve been working away on a few UI improvements of our own! In the upcoming v0.2.1.0 update you’ll not only see us begin to work through the 2024 bug list, but you’ll also see the following changes:

We’ve adjusted the iconography and visuals of intersect nodes to make them easier to interpret (and hopefully easier to learn). We’ve also adjusted the colors of the planned trajectory line to further differentiate from your current trajectory, and shifted the colors on intercept nodes to make it more clear what relation your craft has to celestial bodies. 

Time and space are weird, but through these and future trajectory improvements we’re working on, we hope to make parsing orbital mechanics more approachable!
 

Aaaaaalso as a sneak peek for something that’s coming beyond the v0.2.1.0 update, Jordan has been diligently combing through and adjusting KSP2’s UI in a giant unification pass in order to align some of our disparate visuals. The shot below represents the first wave of style unification on the highest traffic areas of the game:

I’m looking forward to sharing more UI improvements with you all in the future! 

---

Finally, we’ve got an exciting announcement! We’re working on a new promotional video for KSP2, and we want YOU to share your favorite creations with us. It doesn’t matter if it’s a rocket, a plane, a rover, a boat, a giant mechanical turkey, or whatever your heart desires—if you love it and you’re proud of it we want to see it! If we end up using your submission in the video, you’ll be credited and have eternal bragging rights

If you’d like to submit, send an image of your creation along with a craft file (.json) to [email protected]. Please also include your preferred name so we can credit you! (can be real name or username). A bit of fine print here: by submitting your creation, you’re agreeing to let us use the craft file in any and all future marketing materials. Thanks!

We’ll release more details as the trailer project moves forward. We’re excited to take your vehicles out for a spin!

Ness
 

Absolutely spectacular. Thank you

[Bombaatu]

I would suggest having trajectory tag text ("Mun AP", for example) match the color of the trajectory line. This will be especially helpful if two different trajectories had tags close to each other, as is the case in the Mun picture:

Quote

 

 

[Audaylon]

Time to put some extra was on the paddle boat. 

[hatterson]

13 hours ago, RocketBlam said:

I'm not sure what an "under-warp failed control input" is

What they (most likely) mean by this is when you're under timewarp but don't realize it (say you're at 2x or 4x or whatever and well out from Kerbin, you can't tell visually), then you go to adjust your craft. Spinning it so it faces the sun, or trying to burn, or whatever, and the game doesn't accept the input since you can't interact with it during on rails time warp. It's not clearly communicated to you why your attempt to control the rocket didn't work and thus you think "this must be a bug, why can't I turn the rocket" Then maybe you switch to another vehicle or save+reload or whatever which sets warp back to 1x and then you can control it again, further reinforcing that it was a bug that got fixed by your actions versus a timewarp issue.

[K33N]

Love UI design as a field.

Please add back craft typing and type filters at the top, huge constant UI issue in every single player's game that has more than three craft.  Also please make stuff like this impossible:

https://imgur.com/a/p1YtrbG

Edited January 24 by K33N

[kdaviper]

13 minutes ago, hatterson said:

What they (most likely) mean by this is when you're under timewarp but don't realize it (say you're at 2x or 4x or whatever and well out from Kerbin, you can't tell visually), then you go to adjust your craft. Spinning it so it faces the sun, or trying to burn, or whatever, and the game doesn't accept the input since you can't interact with it during on rails time warp. It's not clearly communicated to you why your attempt to control the rocket didn't work and thus you think "this must be a bug, why can't I turn the rocket" Then maybe you switch to another vehicle or save+reload or whatever which sets warp back to 1x and then you can control it again, further reinforcing that it was a bug that got fixed by your actions versus a timewarp issue.

The situation I first encountered this was timewarping and getting close to a CB. Game would let me steer and activate throttle but SAS wasn't working. Then I noticed it entering the atmosphere under warp.

Maybe revert to the way KSP 1 did things. If timewarp gets restricted, set it to 1x automatically instead of the lowest value ( at least when entering physics warp)

[pg17]

The cleaner font really improves things! I can't wait!

On the other side, as others have said, it really emphasize the need to get rid of the pixelated art direction. I understand it might have sounded like a good idea, I understand it was someone's baby and they were proud of it (and in a way, it was consistent and really well done), it's just that it doesn't work regarding readability and effectiveness to communicate information to the player in a game like KSP.

On the opposite, and I know some will disagree and I respect that, seeing the skeuomorphism of KSP1 really makes me like the more contrasted and identifiable color scheme for some elements (like rcs & sas activation, altitude vs speed on the navball, ...).

[Error 403]

Great thread so far.

Some "nice to haves"

• The ability to set a FPS decent/accent rate. Even the Apollo LEM was able to do this on decent.
• Maybe some charts based on what is programmed into KSP 2. Altitude vs velocity to keep from over heating parts. Reentry chart to keep from skipping out all based on mass, velocity and such.

 

[PTNLemay]

20 hours ago, Nesses said:

 SOI transit "bullseye" indicators are too bright, too big, and too prominent relative to other map elements

Personally I do quite like the big bullseye, because when you are at that level of zooming (and this situation with an orbit intersecting an object but not yet captured by it), this is the most important piece of information.  Where am I coming in and where am I leaving?  I imagine (though this is conjecture on my part) that it also helps new players to clearly show one part of the orbit comes out, one goes in.

There is probably a happy middle ground.  Where it can be made smaller but still clearly convey the information it needs to convey.

 

2 hours ago, K33N said:

Love UI design as a field.

Please add back craft typing and type filters at the top, huge constant UI issue in every single player's game that has more.  Also please make stuff like this impossible:

https://imgur.com/a/p1YtrbG

I have to believe that the craft types are on their to-do list, and they just haven't gotten around to it.  Or at least, I really hope that's the case.

Edited January 23 by PTNLemay

[TROPtastic]

14 hours ago, DV-13 said:

What should also help with legibility is removing all zeroes to the left of the timer, they make you look extra hard for the most significant digit in that long string. Compare:

T -0yr:0d:00h:53m:48s

T -53m:48s

I agree it's hard to find the relevant numbers right now, but after thinking about it, I don't think removing all the leading zeroes is the right approach. Leading zeros are used to prevent a timer from resizing as time changes, which can be janky and distracting. See this screenshot of a SpaceX livestream where they work well:

One reason they work here is because there aren't any "h, m, s" labels, but these labels are necessary for maneuvers that will also have days and years of waiting time.

A different approach would be to fade or ghost unused time fields in KSP2, like this:

This prevents the timer from jumping around and resizing itself, but it also highlights the most important information. It also fits with the current theme if you imagine the faded numbers as displays that have been "turned off."

Edited January 23 by TROPtastic

[jclovis3]

21 hours ago, Kimera Industries said:

If you are slowly parachuting down to the surface of Kerbin, you should be able to recover a vessel. I get the fun of landing or splashdown, but let's be honest, that gets old quickly, and getting down to the surface takes sooooo long.

Uh, no on that. You still have to prove your vessel can land and remain stable, especially if it ends up landing on the side of a hill or mountain. Also, depending on your parts, your vessel may sink rather than float on splash down. The speed at which you impact the ground and the mass of the vessel and other attributes all contribute to the chance that your vessel could break apart or even blow up on landing. Your vessel may not slow down enough if it lands in high altitude as the air is thinner and thus the parachutes not as effective.

So in short, a shortcut to recover a vessel that is still falling with parachutes should be an option in the cheat menu or other configuration but not in the default play setup. If you're going to do that, you might as well add recovery of vessel to any CB since one day when we have colonies, we might be using that anyway.

[jclovis3]

12 hours ago, krbvax said:

I also have to wonder about the point of a 2-digit "hours" field when there are only 6 hours in a Kerbin day...

There is an option to use a 24h Earth day in KSP1 and I believe they intend to add that to KSP2 if they haven't already. Standardizing the display output makes it easier to verify screen space usage with either game option being used by the player.

11 hours ago, phuzz said:

One minor issue I've not seen mentioned yet: Renaming vessels.

It took me a while to find out that I could rename vessels via the tracking station (renaming them on the fly via the command pod in KSP1 was handy too), but that's a discoverability issue.

Another important matter to address IMHO is the fact that KSP1 had an auto-naming scheme that relied on optionally set names and priorities for each command module or drone core so that when you dock vessels together, the controlling part with the highest priority and after that, closest to the root node, would set the name of the vessel and when you undock them the same algorithm would determine the name of each vessel. In KSP2, every time you dock or undock you get some random crap like Combined, or your original vessel name with a number appended. Then we have to go back into the tracking station view to rename each one. I just want what we have in KSP1 again. This of course will still be more useful if we could have individual PAWs when we right click a part instead of the part manager's list view.

[TablesRUs]

There are signs of improvement here. However, legibility is still lacking and ultimately needs a lot more polish:

• The ubiquitous use of ALL CAPS text, the continued use of pixelated fonts (e.g. see the "Required delta-v" label in the Trip Planner window) makes it difficult to visually parse this text. It is well-known that spans of capitalized glyphs are less legible than text typeset with proper case (or even small-caps)
• The strangely inconsistent visual weight of various glyphs (see the delta glyph in Trip Planner) draw the eye to unimportant characters
• the aliasing-prone, low-resolution iconography (see the various toolbars along the bottom of the interface and unrecognizably-small icons in the Engineer's Report and window titlebars) are distracting yet unreadable and contribute to an unpolished feel

More generally, I would reiterate the points made in my previous post on this topic with respect to the difficulty of achieving device independence with this pixelated style. The team is preparing an enormous time-sink for themselves by continuing to pursue this art style. I can only hope the remaining hints of pixelation in the example screenshots are merely awaiting their time for replacement; as others have said, it is time to kill this particular darling.

Edited January 23 by TablesRUs

[jclovis3]

5 hours ago, kdaviper said:

Maybe revert to the way KSP 1 did things. If timewarp gets restricted, set it to 1x automatically instead of the lowest value ( at least when entering physics warp)

I'd also like to mention that KSP1 had different colors for physics enabled time warp, and they ranged from 2x-4x. Most importantly, you could use this in space to speed up a slow turning ship by holding right alt while tapping the warp increase > key (at least while entering 2x) to tell the game you want to advance only into the physics warp. After that, if you hit the > key again without the right alt, it would remain within the physics warp speed set and would not go past 4x if you kept hitting it. Returning to 1x would reset it to the normal behavior again so hitting > again would advance you in the non-physics warp mode.

There is a rather troublesome delay, especially with big ships, when you enter or exit the on rails time warp that sometimes messes up your thrust calculations during warp. Tapping the > multiple times during this delay seems to cause more trouble so I tap it once and wait until I see the dV or other trajectory indicators moving again before increasing to a greater warp.

[Superfluous J]

4 hours ago, TROPtastic said:

Leading zeros are used to prevent a timer from resizing as time changes, which can be janky and distracting.

They could always...

...

RIGHT JUSTIFY!

[The Aziz]

4 hours ago, jclovis3 said:

There is an option to use a 24h Earth day in KSP1 and I believe they intend to add that to KSP2 if they haven't already. Standardizing the display output makes it easier to verify screen space usage with either game option being used by the player.

That got me thinking.

There's no use for Kerbin Time when I'm eventually in other star system. The first colony I'd be launching from out there is unlikely to be on a planet with 6 hour long day.

Concept of Sols is needed.