UI / UX Feedback Megathread

[TablesRUs]

1 hour ago, Scarecrow71 said:

Any chance we can get the option to bring back the old way of seeing burn times (instead of right now where it's time to start, go back to the KSP1 way of knowing how long to burn and then starting at the half-way point of that)?

Could you clarify why you think KSP1's approach is preferable? If KSP2's delta-v calculations would be more reliable it seems like the new approach is strictly better. The one instance where I can imagine wanting a burn time instead is in the case of a very small burn, where you plan on using less than 100% throttle to extend the burn duration to improve your chances of precisely hitting the needed delta-v.

If this is your motivation then perhaps a better approach would be to instead offer a way to specify the throttle scale which you intend to use for the burn (e.g. on a logarithmic scale: 1%, 10%, 100%). This setting could be equivalent to just temporarily setting the throttle limit of your staged engines for the duration of the burn. After you discard the maneuver plan the respective throttle limits would be returned to their previous values.

Edited December 2, 2023 by TablesRUs
redundant word

[Brofessional]

Other people have already said it better and in more detail, but I'm definitely not a fan of the pixelated style for font and icons/etc. It's harsh on the eyes, often difficult to read, and many of the icons are monochrome and samey looking which makes them hard to distinguish at a glance.

[Casellina X]

To start with an initial opinion - the UI that was shown in the pre EA footage and captures looked like a more positive direction to go. It felt sleek, modern, and like a major step up for both the Kerbals and players. The Aziz essentially captured a lot of my own sentiment. I feel a very easy way to address many of the concerns players will have would be to swap back to the older UI elements if possible. It's really a double edged sword because I've seen incremental progress on the current theme and have been pleased with some of the changes, and I'd hate for that work to go to waste. So a feature proposal - user selectable theming. Certainly a hefty undertaking, but I think the effort may lend towards longevity of the title as the wants of the community will undoubtedly change over time, and UI mod makers will have the ability to step in and easily contribute. We could retain the pixel theme, bring back the "sleek" theme, and a lot of hard work wouldn't necessarily have to go to waste. As visuals are mostly subjective, a well-defined system put out by Intercept could do wonders.

I think I'm picture heavy so they're all in spoilers.

Spoiler

The colon alignment of Game Time is not the same as with Game Mode/Last Played. The double hash (##) under the back button doesn't seem to make visual sense.

Spoiler

The font used in the credits page content is clean and easy to read versus the pixel-style header font, and indeed many of the similar fonts used elsewhere in the game.

Spoiler

RGB or HEX value inputs would greatly aid usability. Also when you click "Reset Agency Colors", it resets the colors in the left panel (omitted from the picture) but does not reset them in this panel. I think the reset should affect the color picker, and then the user should have to finally click Set Agency Colors to confirm. You know what, an eye dropper tool to pick colors from the set flag would be handy as well, but this is minor in the grand scheme.

Spoiler

Currently going from Easy to Normal only adjusts docking tolerance. Maybe this is an oversight but it seems like Easy should probably toggle Infinite EC, disable probes requiring signal, and enable unbreakable joints.  Note I say this without having switched those toggles myself to see how the game behaves.

Spoiler

If the rest of the UI theme does change, don't let the video player be forgotten.

Spoiler

When I see the numbering on the left, it makes me think maybe the overall design was supposed to represent a terminal or something? If that's the case then moving from the pixel font as a main idea to maybe a more modern looking monospace font would be a good move. There's actually a Google Font called Space Mono… I have a feeling it's being used in the game, but I wouldn't know for certain.

Spoiler

2 things to note here. First is Paige covers the settings screen, I think the settings should have priority. Second is the visual design language changes on this options page versus the initial game setup. If it's buttons in one place, it should probably be the same in others, and same thing for toggles.

Spoiler

I'm going to make it a point not to harp on the pixel-style font, but I do want to call to attention readability. I don't know how badly the forum is going to butcher image sizing, but these were all taken at 1440p for what it's worth.

Spoiler

I think you should add a skip button, either next to continue or an X in the corner so that IF a person wants to, they can skip the tutorial dialog. I understand it's part of the first user experience, but an people might want a quicker way out.

Spoiler

There is no toggle to hide stock craft. The toggle DOES exist when trying to launch craft directly from the KSC. Adding one will help consistency. A question I have is what's the point of the small gray rectangle at the top right of each thumbnail? Just something to keep on the radar. Additionally there is no indication on what sort is currently selected - the default sort doesn't have any rhyme or reason, which is fine, however when you start clicking the toggles they don't show a marker for ASC/DESC. And actually when I closed and reentered the menu, the UI remembered I clicked the Mass sort button, but it reverted to the default sort. Clicking the Mass button again yielded no change, so I had to click the Name button to get the Mass button to decide to work again. Also double check the mouse over behavior when a craft is selected, it doesn't seem like it's working quite right. I'm noticing that if a description doesn't fit within the card bounds, there's no way to see what the rest of it is. Also a Shift+Click or Ctrl+Click to select multiple might be handy.

Spoiler

Another callout on the double hash in front of Statistics. The cushion at the top of the Mass label isn't consistent with the rest. Max Thrust at 1 atm is missing a space between Thrust and 1. And do we need a Min thrust entry on the right? Missing space between the hash and the part manufacturer (which I didn't notice existed until today.

Spoiler

Spacing issue? And the bar prompt lends back into my thoughts that the general theme is a terminal, and doubles my thought on finding a good monospace font to use.

Spoiler

This has been touched on by other users, but the overlapping is a killer. If overlapping is intended and desired, then the windows need to be able to switch Z priorities. Naturally anything stationary should render on top. But if I click the engineer's report, it should send the parts manager to z - 1, and it should render on top. I'll also that that I think maybe we need a right click menu similar to KSP 1. Here and in flight, the Parts Manager can be unwieldy. Another situation where I hate for good work to go to waste, but having both… may not be desirable.

Spoiler

I want to call out that this actually exists, for those of us who overlook it. Also that the dV calculation seems way off for a trip to the Mun and back. Even with how inefficient I am at missions, 10k dV can't be right for a round trip mission. Also the transparent blur ignores the UI element behind it so it effectively erases it and renders what's in the VAB.

Spoiler

A callout for this and the Parts Manager, but man having to expand all of that stuff feels tedious. I don't know if there's  clean solution to this. And a reoccuring thing I've experienced in KSP2 is the state of UI elements not being right. They might think they're in a mouseover state when it first opens, and it only fixes after they've been moused over. Note the "B" on the back button for Lights. Something to fix.

Spoiler

In VAB vs on launchpad. Mismatch on the dV calculation means guesswork by the user. Also on this view, should right clicking on a part icon (parachute, engine, etc.) pull up the Parts Manager for that part? As in an easy shortcut?

Also I think there should be a visual countdown from 10 when the user has that enabled.

Spoiler

I do have to call for that prerelease Nav Ball design to return. I can make due with this, but the visual of the other one was preferable. BUT, a good touch is that when in orbit the colors shift - that makes it very easy to quickly reference if you're on course to make it out of atmosphere. That is something I feel strongly about keeping.

Spoiler

In terms of prioritization, I think the Resource Manager should be swapped with the Flight Report. I don't know how often people open the Flight Report (never for me), but doing fuel transfers and stuff are a common deal. Also would it be smart to roll the Kerbal Manager into the Resource Manager?

Spoiler

Bonus: EVA bug, trying to leave while in flight on the way up. Should have let go due to the forces, I'm assuming. But maybe the forces messed up the local translation?

Spoiler

More of a nitpick, but I don't think chute settings should be hidden behind the toggle.

I think a Recover Vessel option should appear on planets that you've got a KSC present when you're in a Landed state on a planet after having been In Flight. This is a stubborn hold over from KSP 1 making it fairly easy. The first time player may not immediately think to pull up the Escape Menu. And thinking back to the Flight Report, if it is retained then adding a recover button inside of it (given the flight state changes) could be a good move. I also say this after forgetting the behavior of the Recover Vessel button in the escape menu. But all things to keep in mind.

Spoiler

Alignment issues.

Spoiler

The tutorial descriptions are not easy to read in this font, at this size, even after putting my glasses back on. Also another sticking point is there's no easy button to leave, you have to pull up the Escape Menu.

Spoiler

The KSC icon half submerged in the surface needs some fixing. And while I didn't capture it here I'd like some way for a little more precision when selecting a point along the arc for a maneuver node. Even if it's just making that ability possible while the game is paused, as it currently doesn't work.

Spoiler

So onto the maneuver node. I really, REALLY miss being able to use the mouse scroll wheel to increase or decrease the dV in the moused over direction. I also really miss the AP/PE in the bottom left readout (I think that's where it was) showing your expected AP/PE when they currently selected maneuver was executed. It makes it very difficult (for me) to quickly plan things and it creates a headache trying to position the Map View in a way that I can do what I need to do. In general, both in Flight and Map View, we're sorely  missing on orbital information - I say this as a 99% stock player in nearly every game, I don't want to have to turn to mods for that sort of thing. This something that definitely needed to be carried over from KSP 1.

[Poppa Wheelie]

I'm copying @Casellina X's image here

This is not the way to read the dV map.  All of the text for the return trip is incorrect.  This will definitely be very misleading to new players.  From Kerbin surface, to a Mun landing, and back to the surface of Kerbin, should read like this:

• 3400     Kerbin to LKO
•    860     LKO to Mun Intercept
•    280     Mun Intercept to Low Mun Orbit
•    580     Low Mun Orbit to Mun Surface
•    580     Mun Surface to Low Mun Orbit
•    280     Low Mun Orbit to Elliptical Kerbin Orbit
•    860     Elliptical Kerbin Orbit to Low Kerbin Orbit
• 3400     Low Kerbin Orbit to Kerbin Surface

And then the tutorial on how to use this tool should explain to new users that they can skip the last 2 steps (and associated dV) if they aerocapture at the LMO to EKO step, or that they can skip the very last step unless they intend to do a completely powered landing.

[The Aziz]

5 hours ago, Casellina X said:

The font used in the credits page content is clean and easy to read versus the pixel-style header font, and indeed many of the similar fonts used elsewhere in the game

This is the best one they have right now. The whole game could switch to that.

5 hours ago, Casellina X said:

 

  Reveal hidden contents

I'm going to make it a point not to harp on the pixel-style font, but I do want to call to attention readability. I don't know how badly the forum is going to butcher image sizing, but these were all taken at 1440p for what it's worth

Now it's clear that the game wasn't designed with 1080p resolution in mind. The pause button is the very first evidence.

3 hours ago, Poppa Wheelie said:

This is not the way to read the dV map.  All of the text for the return trip is incorrect.  This will definitely be very misleading to new players.  From Kerbin surface, to a Mun landing, and back to the surface of Kerbin, should read like this:

• 3400     Kerbin to LKO
•    860     LKO to Mun Intercept
•    280     Mun Intercept to Low Mun Orbit
•    580     Low Mun Orbit to Mun Surface
•    580     Mun Surface to Low Mun Orbit
•    280     Low Mun Orbit to Elliptical Kerbin Orbit
•    860     Elliptical Kerbin Orbit to Low Kerbin Orbit
• 3400     Low Kerbin Orbit to Kerbin Surface

And then the tutorial on how to use this tool should explain to new users that they can skip the last 2 steps (and associated dV) if they aerocapture at the LMO to EKO step, or that they can skip the very last step unless they intend to do a completely powered landing.

The return trips are wrong altogether, check other planets. And even fully powered landing on Kerbin won't ever take 3400 because there's an atmosphere. Few hundred m/s at most.

[Scarecrow71]

15 hours ago, The Aziz said:

Click on the altimeter. Wouldn't that be the first thing to come to mind while looking for the feature? Assuming you knew how to switch between surface and orbital modes for velocity.

I have.  Nothing happens.  At least, nothing I've noticed, anyhow.

13 hours ago, TablesRUs said:

Could you clarify why you think KSP1's approach is preferable? If KSP2's delta-v calculations would be more reliable it seems like the new approach is strictly better. The one instance where I can imagine wanting a burn time instead is in the case of a very small burn, where you plan on using less than 100% throttle to extend the burn duration to improve your chances of precisely hitting the needed delta-v.

You pretty much covered the why in these sentences.  KSP2's dV calculations are off, which makes the burn time off.  And for very small burns, where you plan on using less than 100% of the throttle.

Granted, the muscle memory factor plays a part in this; it's how I learned in KSP1.  And yes, your mileage may and probably will vary.  But if we are calling out stuff we'd like to see...

[The Aziz]

And have you tried in a place that has a diference between ground at sea level? Works for me.

https://i.imgur.com/Su3Cl65.mp4

[TablesRUs]

28 minutes ago, Scarecrow71 said:

You pretty much covered the why in these sentences.  KSP2's dV calculations are off, which makes the burn time off. 

It doesn't seem reasonable to design UX around the assumption that the product will not behave as designed, especially when we are discussing something as foundational as delta-v calculation in a game about space travel. If this is how UX design was conducted then most UIs would look much different than they do, largely for the worse.

[Scarecrow71]

12 minutes ago, The Aziz said:

And have you tried in a place that has a diference between ground at sea level? Works for me.

https://i.imgur.com/Su3Cl65.mp4

I honestly can't tell if you are joking, or if you think I don't know how to play the game.  Yes, I've tried in multiple spots where there is a clear difference between ground and sea level.  On multiple celestial bodies.

[Poppa Wheelie]

5 hours ago, The Aziz said:

The return trips are wrong altogether, check other planets. And even fully powered landing on Kerbin won't ever take 3400 because there's an atmosphere. Few hundred m/s at most.

Agree.  All text for all return trips is incorrect, because the approach being used is just to mirror the text used on the outbound trip.  The tool does return trip text incorrectly in every case.  I was just using Mun as an example.

Agree that even a powered landing on Kerbin won't need most of the 3400.  To be generic enough to cover all cases, let me change my recommendation for the tutorial.  The tutorial should specify that all or most of the dV for the "low orbit" to "landed on" step will not be needed for a body with atmosphere - the more significant the atmosphere, the less of the listed dV will be needed.

[The Aziz]

26 minutes ago, Scarecrow71 said:

I honestly can't tell if you are joking, or if you think I don't know how to play the game.  Yes, I've tried in multiple spots where there is a clear difference between ground and sea level.  On multiple celestial bodies.

Well what can I say other than it works for me as presented in the linked video. Why it doesn't change the mode after your clicks, I can't tell.

[TablesRUs]

13 hours ago, Casellina X said:

We could retain the pixel theme, bring back the "sleek" theme

At the risk of venturing too far into the realm of "suggesting solutions", which we were asked not to do:

I would hope that IG recognize that this isn't a prudent path forward. The current pixelated interface is very far from being acceptable and will take a considerable amount of work to make it functional across the wide array of devices that they need to support. This is because that by committing to a pixelated style they are giving up a plethora of anti-aliasing techniques which make it possible to produce interfaces that scale easily and clearly to a wide array of display geometries and densities; afterall, most anti-aliasing techniques involve some amount of interpolation, something which you intentionally need to avoid to maintain a crisp pixelated look. This leads to very painful design trade-offs as one must either:

• compromise the style by trying to remain device agnostic and accepting that users with low-to-moderate pixel densities will see a muddy mess as they lack the resolution to crisply realize the clean lines you intended
• design graphical elements to target the lowest-common-denominator of pixel density and accept that a (hopefully-small) amount of anti-aliasing will be necessary on some display geometries. However, such an approach significantly limits the amount of screen real-estate and detail that you have at your disposal. Given that users with very low pixel counts (e.g. TVs and low-end monitors) are too common to ignore, this isn't something that users with more modern display devices would appreciate.
• painstakingly design graphical elements for an array of pixel densities. Naturally, this leads to very difficult decisions (e.g. "should the dot in this icon be two pixel or three pixels at 100 dpi? what about 200 dpi? oh, but this other dot elsewhere needs to be three pixels in its context and yet should have the same weight as a dot which we can only afford to give two pixels..."). There is a good reason why interfaces are no longer designed this way.
• Some hybrid of the three; this appears to be where we are today, with some features being faithful to the style ("sharp") while others are muddy; some features are needlessly large, while others suffer from awful visual inconsistencies (e.g. some have significantly more visual weight than others which should look similar)

Add to this difficulty the fact that it is extremely common to consume the game in compressed form (e.g. via Twitch, YouTube, or Remote Play). High frequency features like those found in the current style are anathema to the psychovisual models on which most video compression schemes are based. It is nigh inevitable that even a well-implemented pixelated style will look like mush via such a channel.

Finally, there is the fact that all code has a cost. This is especially true for systems like user interfaces, which are notoriously hard to test and very platform dependent (and made even more so by the pixelated style). Keeping two interfaces in the tree would be incredibly expensive and would split attention in an area of the project which badly needs focus.

Ultimately, I can't speak to why IG thought that the pixelated look would be worth the effort given that they had a perfectly reasonably-looking interface concept years ago. It should be clear to someone with a graphics background that the pixelated design was going to be challenging at best, with the result inevitably looking mediocre to at least some targeted players; the best you can reasonably hope for is that it would look "okay" for "most" players.

I hope that IG sees the writing on the wall and writes off the current design as an interesting, but ultimately doomed, experiment. This would allow a change of course before more effort is put towards the Sisyphean task that otherwise lays ahead of them. Yes, perhaps this will mean discarding some sunk cost but reverting to a smooth style will almost certainly be easier than the alternative, and will certainly produce a better, more predictable, and easier-to-evolve result.

Edited December 2, 2023 by TablesRUs
Word-smithing

[Fluke]

Can someone point me to where the old UI video/screenshots are?? I knew I saw it at one time, but can't find it. 

[The Aziz]

2 minutes ago, Fluke said:

Can someone point me to where the old UI video/screenshots are?? I knew I saw it at one time, but can't find it. 

In my repo for example, button in signature.

[TablesRUs]

7 minutes ago, Fluke said:

Can someone point me to where the old UI video/screenshots are?? I knew I saw it at one time, but can't find it. 

See the above post from The Aziz. He provides a good number of examples.

[Fluke]

@The Aziz @TablesRUs thanks!

[Wheehaw Kerman]

First off, the flight interface.  
 

I like the navball, and I like the placement (but would support all flight UI display elements being moveable).  I like the tapes.  That being said, it could benefit from

1) being compacted a bit.  It does waste some screen real estate - notably in the gaps between the sidebars and the main navball.  I’ll second the guys pointing at the white space.  Pushing it over to the edge of the screen wouldn’t hurt.   With a clearer font it would not lose legibility.

2) integrating the G-force gauge (it was ages before I realized it was up with the crew and for some reason).

3) a clearer font.

The docking mode/flight mode controls would benefit from being in their own little panel.  There’s plenty of room to squeeze them in somewhere in the vicinity of the navball.

The Burn Timer.  How I love it, but again, wasted space, and unclear font, bother me a little.  Outing myself as a countdown nerd (timers are my fave watch/phone clock feature and I use them a lot IRL), I think the countdown to burn sound and visual cues are fantastic, but I’d love to see more voice time checks in Kerbalese at the 10, 5, and 1 minute marks, with the time remaining feature flashing concurrently.  A DeltaV expended/remaining display would also be useful.

I have mixed feelings about the parts manager.   On the upside, being able to rapidly navigate around parts categories is quite useful.  On the other hand, the ability to pull up multiple small panels for different parts and pin them KSP1 style is something I sorely miss.

[HebaruSan]

On 11/30/2023 at 5:54 PM, Dakota said:

I've had multiple meetings with the team going over your requests

First, thank you for doing this! We can expend as much effort reporting and analyzing issues as we like, but unless someone does the work of gathering, summarizing, and presenting it to the folks in the trenches, it's all for naught.

Frankly, so many things are wrong with the current UI that I doubt that a one-fix-at-a-time approach can be successful. A root cause analysis of what went wrong is needed to determine how to move forward. Is there no UI/UX designer in-house? Hire one, pronto! Is there one but their advice was ignored or bypassed? Give them more authority within the team, such as mandatory reviews and sign-offs before feature branches get merged. Is there one and their advice was heeded but poor? Replace them (carefully!). It's essential that interfaces be designed competently before they reach the point of end users giving feedback, because at that point you're going to get an overwhelming mass of bullet points as users pick the dozen nits that irked them individually (see above and below!).

Before specific gripes, a general rule: Never prevent the player from doing something unless it is impossible or will 100% ruin something. You may think you have a good reason to disallow an action, but if the player thinks they have a good reason for wanting to do it, the player should win that argument every time, especially in a creativity-focused sandbox game with a "learn by failing" ethos. Give feedback or ignorable warnings if you think there's a high chance of unintended outcomes, but never just refuse to comply with a comprehensible request. This rule of thumb has been tripped over in several instances already (time warp limits, maneuver delta v limits, entering the Tracking Station from the VAB), but it's important to get clear on the general principle to avoid repeating the same fundamental error in future features.

Workspaces! I can't tell what they're for. The fact that the name "workspace" is in the UI instead of just "vehicle" or "craft" implies that they do something in addition to just holding a craft, but I can't figure out what that is supposed to be. The save dialog says "SAVE VEHICLE" and "EXISTING SAVED VEHICLES", and the first thing it prompts for is "Workspace File Name", are you starting to see why this is confusing? (Note to readers: Past this point I am going to type questions, but I am not seeking answers for them! They are my attempts to represent my puzzled reaction to this feature and how it could be made clearer. Please do not answer them here!)

• Is a workspace meant to represent: one craft? one category of crafts, like all of my spaceplanes? one project, like a multi-part space station? Is it supposed to contain multiple revisions of one craft over time? What exactly is supposed to be grouped within a "workspace"?
• Why am I prompted to enter two names, workspace and craft? At a glance it seems redundant. The existence of two names suggests that a workspace can represent multiple craft, but that's contradicted by the fact that each workspace can only have one craft name. What is the use case in which they would be set differently, and to what?
• In the loading and saving screens, I see previous revisions of my current craft, which suggests I'm looking at older versions of it within the current workspace, but I also see completely unrelated crafts, which suggests this is a listing of all my crafts. But the current craft shows up multiple times, because...?
• The description of my workspace says "AutoSaved workspace" with a timestamp, but I've saved over it manually. Maybe don't default in that string, or clear it when overwriting manually?

The message after a vehicle is destroyed sounds passive aggressive / snarky ("That could have gone better" or somesuch?), which compounds irritation and depletes goodwill when a bug is involved. It reads like the character is commenting on your failure as a disinterested third party, from the outside. Instead they should be commiserating like a team member dealing with a shared trauma in the first person plural (maybe something like, "Oh, no! Well, don't worry, I'm sure we'll figure out what went wrong there!").

When making a maneuver node, I have to click it again to edit it (I think?), just open it by default since that's what I want every single time.

The majority of the info the Parts Manager displays is useless and unrequested; if I right click a command pod, I don't need to see a non-interactive list of all the fuel tanks as well, and the cost in valuable screen real estate is stupendously high when it covers the craft I'm editing. An easy fix without starting over would be to only show parts in the Parts Manager that the user has right clicked on. If I right click one part, show just that one part, and only add more if I right click more parts. Remove them if I right click again (or click an X within the PM). Bonus points for auto-sizing the window to fit.

I'm in the VAB, and I want to go to the Tracking Station. Why can't I? The option is disabled in the Esc menu:

Others have commented on the ugly frame header text in the flight UI; I'd suggest simply removing those and making sure it's easy to tell what the content is without them. Is anyone going to have an "Oh, I get it!" moment after squinting at "APPS" for several seconds to be able to read it? What could "APPS" even mean to a player?

On a partially-occupied vessel, the seat cameras show empty seats by default, requiring scrolling to find the crew, and I think that even resets itself to empty seats in various cases. Show the seats that have crew in them first!

Edited December 2, 2023 by HebaruSan

[Scarecrow71]

I need to add something to the list of stuff I put out there before:  TWR Readout.  As far as I am aware, there is no TWR display anywhere once you leave the VAB.  And even in the VAB, the Engineer's Report only gives TWR for the launch stage.

KSP1 had TWR per stage included with the dV calculations in each stage.  You could expand a given stage and see both dV and TWR, and that was really helpful.  Please bring this back.

[HebaruSan]

On 12/1/2023 at 2:57 PM, The Aziz said:

Inconsistency, that may be long.

  Hide contents

Because for some reason, of four windows visible here, each one has a different style. The sizes, the fonts, the colors...  Even the title bars are different. Some are resizeable, some aren't... And it follows throughout the entire game.

Oh dear, that looks like they're hand-editing those in some kind of GUI designer in Unity without a library of shared components. You can see that some consistency was attempted by the common "TITLE -----/" pattern in the headers, but the background colors alone make it obvious that there isn't yet a common "dialog prototype" to be re-used.

On 12/1/2023 at 2:57 PM, The Aziz said:

And you had such great ideas during development:

  Reveal hidden contents

It's as clean as day and even has hints where other attitude markers are, it's glorious. And it followed on the entire interface, I believe, even with few hiccups (the LCD font in places etc) it was one of your best yet.

  Reveal hidden contents

Same with VAB. Nice, clean modern design, smooth iconography, perfect for a space age game

  Reveal hidden contents

You even had the same or very similar icons in the interface in the last 4 years, but decided to pixelify them. Shame.

Are we sure those weren't just mock-ups? Maybe the current state is just what happened when they tried to make the transition to functioning code.

[The Aziz]

57 minutes ago, HebaruSan said:

Are we sure those weren't just mock-ups? Maybe the current state is just what happened when they tried to make the transition to functioning code.

No, there's footage in episode 6 with those early designs in action somewhat, they're not just static images. They worked on some level. But also... How on Earth is changing the visual style gonna break the code?

[HebaruSan]

2 minutes ago, The Aziz said:

How on Earth is changing the visual style gonna break the code?

"Break" doesn't describe the scenario I was imagining: Artist mocks up some screenshots in photoshop, which look great, and hands them to developers, who struggle to implement some of the ideas fully in Unity without additional assets and eventually end up at the current mess.

Moot if those are from videos, though.

[Sans]

I really prefer the pixelated art syle to the old UI shown in eraly dev, I said it, I think it. As other said, fonts being aligned, more visible (by disabling anti-aliasing or bilinear filtering) and the UI less cluttered, is a 100% go for me

[Spicat]

I'm absolutely fine with the current style (even for some pixelated things here and there), and it's all subjective either way so I don't think they should change that, they will just waste time to satisfy a part of the community but anger another part.

However, the pixelated look is only good when the item is big. So for big text it's fine (like the GO button, the trip planner or the huge title in the credit shown above), but for small text (like the different box descriptions or the navball) they should use the smooth font.

Also, I think that all icons should be smoothed, Minecraft got away with it because there isn't that much information and every text/icons are really big compared to most of the stuff in ksp2. That will absolutely not changed the style.

 

A really bad mockup where I smoothed some of the things:

[Bej Kerman]

On 12/3/2023 at 12:25 AM, Spicat said:

A really bad mockup where I smoothed some of the things:

I think this opens up more inconsistencies than there already are. I love how the pixelated style looks at native resolution but it's fundamentally flawed in that it breaks at any other resolution. The UI needs to be composed of images or vectors and designed to look the same when interpolated at different scales as the current artificially-aliased look does not accomplish that. Just replacing some elements like in your mockup won't help fix the fundamental issues at hand.