SQUAD

KSP Loading... Preview: New Altimeter Toggle!

Recommended Posts

Posted (edited)
23 minutes ago, FleshJeb said:

Oddly enough, that's the ONE gauge I DO use on that entire cluster (spaceplane ascent shenanigans). I have KER set up to display the rest in a more compact format.

OK, OK, I can live without it; you guys can have the space.

I use it too, but only when I don't need to be too precise about when I stage off fairings, or switch mode on Rapier engines, or see how fast reentry is progressing. Although, since the TWR display was introduced along with delta-v in the staging display I use that now more often to see when I need to switch over to orbital engine mode.

After a few launches you get an intuitive sense for these things. I'll be the first to admit that the atmosphere density gauge helps to tune that intuitiveness, so I'm not suggesting to eliminate it. I'd just love to see it in a smaller, vertical aspect.

Edited by HvP

Share this post


Link to post
Share on other sites
Posted (edited)

Finally lol. I have always considered this a major annoyance, especially when landing in the dark. 

Edit: I also agree with everyone else that it is probably about time that part of the UI gets a bit of an overhaul as well.

Edited by MechBFP

Share this post


Link to post
Share on other sites
23 hours ago, Raptor9 said:

Great addition to the UI @SQUAD.  :) At the risk of jumping on the dog-pile of community UI suggestions, I have the following example, which includes some previous suggestions in this thread.

UI%20Suggestion_zps8yrra8nn.png

From right to left:
1) Making the toggle a defined button along with the other three already along the right side not only uses space more wisely, but it also clearly denotes to users that it is a button.  When I first started out, I had no idea I could manually toggle between Surface/Orbit (or Target) modes on the navball by clicking the velocity readout.
2) Placing the altitude mode indicator next to the button that toggles it is also more conducive to user interface principles.
3) I'm in agreement with @Jacke and others that having to constantly swap between flight and map scenes just for Apoapsis/Periapsis altitude readouts is cumbersome.  Placing them below the current altitude readout allows the user to compare where they are currently at versus where their Ap/Pe is.  And based on the vertical speed indicator to the right, they can determine which one they are heading toward. (If the VSI is positive, the Ap will be intersected next, if the VSI is negative the Pe will be intersected next) And obviously there would need to be an "asterisk" somewhere in KSPedia pointing out that the Ap/Pe are always gonna be in ASL format.

As a final suggestion, would it be possible to add a discreet SAS sub-mode while in "Stability Assist" in which the craft will hold the current attitude in relation to the horizon, instead of the universal attitude?  This would make maintaining level flight less of a headache during long atmospheric flights in Kerbin/Laythe, or even rocket powered VTOL's flying at low altitude across the Mun or other small bodies.  In lieu of adding yet another button, I imagine it would be conducive to have the SAS hold the attitude referenced to the horizon when in "Surface" velocity mode, and hold referenced to universal attitude when in "Orbit"/"Target" velocity mode.

I could be wrong about that last sentence, since other players build and fly different styles than me, so that suggestion might need a little polish. :)

EDIT: To be honest, the mish-mash of buttons, clickable digital readouts, analog gauges and such could probably use a more standardized format.  One that keeps the Kerbal feel to it all, but has a more consistent presentation for easier data intake.  But now we're talking about a fairly invasive UI revision, and I doubt that's on the table at this point. :P

Couldn't Atmosphere gauge be replaced by Pe once Pe above the atmosphere after that it is wasted space?

Making more room for Ap to be nice size for readability.  Hey Personally I don't think any button other than abort should be at the top of the screen like this. Which means gauges could all be arranged in a longer

Yes full overhaul of UI would be great also would be fun to see different layouts for different cockpit types.

Share this post


Link to post
Share on other sites
On 3/5/2019 at 9:15 PM, nestor said:

Thanks for all the feedback related to the UI, we will keep those comments in mind. 

Everyone's making UI suggestions to rearrange all sorts of buttons and lights and whatnot, but we seem to have missed the easier option, which already has precedent on the speedometer. Just click the actual readout to change between modes, maybe have the red background on the unit ticker change colour to indicate mode switch. That's it. No new buttons, no rearranging the existing UI, new function with more elegant implementation. (Prepare for arguments over what colour the display should change to. Red is my favourite but since it's already red, I vote green.)

Or the alternative route that some mods take where the altitude display mode is tied to the navball speedo's reference frame, ie selecting orbit or surface mode would make it automatically switch between ASL/AGL. No UI changes needed at all that way.

Share this post


Link to post
Share on other sites
5 hours ago, Loskene said:

Everyone's making UI suggestions to rearrange all sorts of buttons and lights and whatnot, but we seem to have missed the easier option, which already has precedent on the speedometer. Just click the actual readout to change between modes, maybe have the red background on the unit ticker change colour to indicate mode switch. That's it. No new buttons, no rearranging the existing UI, new function with more elegant implementation. (Prepare for arguments over what colour the display should change to. Red is my favourite but since it's already red, I vote green.)

I like the cut of your jib, kid.

Share this post


Link to post
Share on other sites
5 hours ago, Loskene said:

but we seem to have missed the easier option, which already has precedent on the speedometer. Just click the actual readout

Klesh and 5thHorseman have you covered.  See the thread that each of them linked to, in their posts up above.

Share this post


Link to post
Share on other sites
10 hours ago, Loskene said:

Everyone's making UI suggestions to rearrange all sorts of buttons and lights and whatnot, but we seem to have missed the easier option, which already has precedent on the speedometer. Just click the actual readout to change between modes, maybe have the red background on the unit ticker change colour to indicate mode switch. That's it. No new buttons, no rearranging the existing UI, new function with more elegant implementation. (Prepare for arguments over what colour the display should change to. Red is my favourite but since it's already red, I vote green.)

Or the alternative route that some mods take where the altitude display mode is tied to the navball speedo's reference frame, ie selecting orbit or surface mode would make it automatically switch between ASL/AGL. No UI changes needed at all that way.

You can also click the actual readout, we did not miss the comparison to the orbital/surface speed display.

As for form factor of the display, that's still a bit of a WIP.  

Share this post


Link to post
Share on other sites
Posted (edited)

Yes, at last..

Good to see some more of these small, but significant, additions getting included.  

Edited by pandaman

Share this post


Link to post
Share on other sites

This is a great change and a mystery of why it took so many years to get implemented!

Share this post


Link to post
Share on other sites
9 hours ago, Maxsimal said:

You can also click the actual readout, we did not miss the comparison to the orbital/surface speed display.

As for form factor of the display, that's still a bit of a WIP.  

Ah, excellent, I must have missed that.

Yeah I understand the UI is still "programmer art" right now. Maybe it's not a bad time to give that entire UI element a fresh coat of paint, as others have said, it is a little old by now. Looking forward to seeing the final version in any case. I have so many "essential" mods for tiny QoL changes like these, that I'm very excited to have them in stock.

14 hours ago, klgraham1013 said:

I like the cut of your jib, kid.

Whenever I think about an addition to a game, I always make my first train of thought "is there a way to implement this using mechanics/features that are already present?"

I'm no pro game designer but it always seemed the logical path to minimise workload and maximise cohesion of game elements. Something I often criticised Elite Dangerous' design for was the sheer lack of mechanical cohesion and wasted work that went into refactoring half the game for every new thing they added. Squad have been far better at this to date in my estimation.

Share this post


Link to post
Share on other sites

Why not split the altimeter cluster into snap-together widgets?

Have the current setup as the default, but allow players to enable/disable each separate element and arrange to their taste

Share this post


Link to post
Share on other sites

I agree with the general view that extending the UI vertically isn't the greatest idea, and introducing wasted space into a central UI element is even less great.

But for me, at least as far as I can see, the biggest problem is that there is no indication that this thing is can be toggled or clicked on. The UI for the altimeter "plate" looks just like all of the other background elements in the flight screen UI.

Expecting players to watch a video where the button is highlighted, or sift through a 100 page encyclopedia, or sit through a tutorial is a terrible way to teach players how to use the UI. Basic UI functions should not hidden features.

There should be some kind of visible "button" element added to the UI to toggle the altimeter function, it could be like others have suggested alongside the existing buttons on the right, or something on the left. And while you're at it, something similar should be done for the navball speed indicator and the stage panel extended info boxes (maybe make the stage icons have an arrow icon that switches from pointing right or left depending on whether the info box is open).

Share this post


Link to post
Share on other sites
7 hours ago, DMagic said:

I agree with the general view that extending the UI vertically isn't the greatest idea, and introducing wasted space into a central UI element is even less great.

But for me, at least as far as I can see, the biggest problem is that there is no indication that this thing is can be toggled or clicked on. The UI for the altimeter "plate" looks just like all of the other background elements in the flight screen UI.

Expecting players to watch a video where the button is highlighted, or sift through a 100 page encyclopedia, or sit through a tutorial is a terrible way to teach players how to use the UI. Basic UI functions should not hidden features.

There should be some kind of visible "button" element added to the UI to toggle the altimeter function, it could be like others have suggested alongside the existing buttons on the right, or something on the left. And while you're at it, something similar should be done for the navball speed indicator and the stage panel extended info boxes (maybe make the stage icons have an arrow icon that switches from pointing right or left depending on whether the info box is open).

In principle that makes sense, but I think there are more subtle ways of indicating the mode select options without the use of additional UI elements like lights or buttons. My reasoning for this thinking is that the navball speedo has no buttons or indication that it can be switched between orbit/surface/target velocity, but because it automatically switches itself based on flight context, the player is made aware that it can be changed, and the first thing most people will think of for how to change it manually is to click on it. So even without an obvious notification, the player always learns they have control over it. The system seems to work pretty well there, at least I've heard no complaints about it being too opaque to discover. If the altimeter likewise automatically switched over in the same contexts it should in theory be just as accessible. It will still need an indication that it has/can be changed, seeing as the speedo says which mode it's in, so a change of background colour or something like that should perform the same function with minimal impact.

I suppose it depends on whether they plan to keep the existing UI or refactor it completely, in which case more obvious controls may fit more nicely into a new design that's built with them in mind, but the two ideas needn't be mutually exclusive, either simple colour/text change or discrete buttons would work in that case, whatever ends up being the better blend of form and function. If we're just keeping the current UI though, I think it preferable not to bolt any more on to it, and the more subtle approach may be the better one in that scenario. Either way it should ideally be consistent between all switchable readouts that behave the same. If the altimeter gets its own mode switch button, the speedo probably should too.

Would be interested to hear the thoughts of whoever's in charge of UI design on this, there are numerous options depending on how much labour is to be committed to this (admittedly minor) task.

Share this post


Link to post
Share on other sites
Posted (edited)
4 hours ago, Loskene said:

Would be interested to hear the thoughts of whoever's in charge of UI design on this, there are numerous options depending on how much labour is to be committed to this (admittedly minor) task.

Hey I'm not the designer primarily in charge of UI/UX, that's @Bea_Pin, but I'll share some of what goes into it.

Even a fairly minor task takes a chunk of time when you have to consider the feature as a whole.  We actually have done almost a dozen different mockups with ideas & variations of the AGL/ASL design.  


Without diving too deeply into how the sausage is made, all of the following get considered:

1. What sort of affordance the UI requires.

An affordance is something that lets the user know the action of the UI element. 
The more advanced a feature is, the less affordance we tend to give it, because they take space and we have dozens upon dozens of functional UI elements on screen at once.  Not to toot KSP's horn too much, but compare it to many flight simulators - that still don't have to support as many situations or as much information as KSP - and how much screen space those games tend to cover with their on-screen UI, and you'll see KSP packs a lot of punch into a relatively low % of the screen.

2. Current UI style 

Not only do we not want to rework things too much for the sake of dev time, but we have a lot of very conservative players who don't like too much change.  And we don't want to shuffle around UI elements that the player is already familiar with - that's one reason we didn't decide to swap the climb rate indicator out for a radar altimeter.  

3. Localization

One of the reasons this initial variant was selected was to give enough space for localization - we sent off text early for localization to see if we could get 'ASL' and 'AGL' to fit on buttons initially, and found that the Japanese and Chinese variants text was overlarge for what one of our ideas would handle.

4. Player capabilities

This includes: how small a screen resolution we need to support, to color blindness, to vision issues that mean we try to keep all functional text at 12pts or more.

----------------------------------------------

To give a concrete example: we hide away the advanced delta V information behind clicking on the stage icons - that's not a great affordance at all, but that information is more for a power user, and lets us keep the screen space usage down and the stage UI style the same as people are used to.  The stage information flyouts also mean we have a bit more space for text on those.


Even with all that, we don't think we get it right all the time - so we give out previews to both our pioneers group and to the audience to get feedback.  When we see feedback we do evaluate it - and compare the cost of additional changes vs work on other features in the pipeline.


 

Edited by Maxsimal

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, Maxsimal said:

... we give out previews to both our pioneers group and to the audience to get feedback. 

As far as UI and UX goes, graphical previews through screenshots of concepts almost amount to nothing in quality feedback compared to actually sticking a working concept in the test subjects' hands. I sure to God hope that you actually give this Pioneers Group a working example of the UI to play with and then garner feedback post-test otherwise that kind of goes against everything I've even been taught or teach about the all encompassing topic of UX. 

The clue is in the name, User Interface/Interaction and User Experience. The two most important aspects of this subject cannot be fully explored merely with screenshots of a developers mock up.

I'm sure your Producer has this fully in hand, however, and the group were able to give some quality hands on feedback. It's nice to hear that upon the feedback of the wider audience (the players on this forum) that the area is going to get some further investigation and revision.

Edited by Poodmund
Spelling

Share this post


Link to post
Share on other sites

If you’re reworking that area, I would like to add that I have well over 2,000 hours in this game and there are still elements of that upper central UI that I have no idea what they do.  Specifically the little triangle and the little light next to the rate of climb circular dial.    I have never once gone into the Kerbalopedia or whatever that thing is to find this (or frankly anything ever) out.

Share this post


Link to post
Share on other sites

@Maxsimal

I really appreciate this feature being added to the game. Like many others here I've had too many otherwise successful flights/missions go splat due to misjudging my distance to the ground, I've found this to be especially frustrating as a casual player with limited time to play.

However I wonder if the flight info could be further improved by clearing up the dial of the climb rate indicator? I play on a low spec laptop and even on the best graphics settings I can run I can't see the numbers on the dial.

Regardless of the final UI design this will be a very worthwhile addition.

Share this post


Link to post
Share on other sites
Posted (edited)
6 hours ago, Maxsimal said:

I'll share some of what goes into it.

Even a fairly minor task takes a chunk of time when you have to consider the feature as a whole.  We actually have done almost a dozen different mockups with ideas & variations of the AGL/ASL design.  


Without diving too deeply into how the sausage is made, all of the following get considered:

Thanks for that insight. :)

EDIT: I do like the suggestion somebody made about using pictorial symbols instead of spelling out "ASL" or "AGL" in order to bypass the localization translations and space requirements.  Like maybe a flat blue line representing the "Above Sea Level" mode and a green or brown mountain symbol for "Above Ground Level".

UI%20Suggestion%202_zps09xzit12.png  Or some monochrome version for resolution purposes.

Again, not trying to minimize the impact subtle changes make in the UI, because I'm definitely no programmer.

Edited by Raptor9

Share this post


Link to post
Share on other sites
2 hours ago, Raptor9 said:

Thanks for that insight. :)

EDIT: I do like the suggestion somebody made about using pictorial symbols instead of spelling out "ASL" or "AGL" in order to bypass the localization translations and space requirements.  Like maybe a flat blue line representing the "Above Sea Level" mode and a green or brown mountain symbol for "Above Ground Level".

Again, not trying to minimize the impact subtle changes make in the UI, because I'm definitely no programmer.

Cheers, thanks :)

The best solutions are usually the ones where someone goes “well, instead of doing all that, how about you just do this?”

Share this post


Link to post
Share on other sites
12 minutes ago, Jognt said:

Cheers, thanks :)

Ah yes, it was you. I was going back through the thread trying to find where I saw that, but I must have missed it.  I was starting to think I spotted it in another thread until just now.

Share this post


Link to post
Share on other sites
Posted (edited)
7 hours ago, Maxsimal said:

. What sort of affordance the UI requires.

An affordance is something that lets the user know the action of the UI element. 
The more advanced a feature is, the less affordance we tend to give it, because they take space and we have dozens upon dozens of functional UI elements on screen at once.  Not to toot KSP's horn too much, but compare it to many flight simulators - that still don't have to support as many situations or as much information as KSP - and how much screen space those games tend to cover with their on-screen UI, and you'll see KSP packs a lot of punch into a relatively low % of the screen.

Thanks for responding, but your technical explanation just shows how far the considerations you described are from the actual design. The current readout is all over the board in terms of "affordance". Critical items like "Abort" are not even clearly identified as an interactable element.  "Atmosphere", which is IMHO the least useful element, gets space to have the word fully spelled out. 

OWhDJF9.jpg

Since Squad has managed to include such a variety of styles into this one UI element I think it's safe to say you can go in any direction you want. The preponderance of opinion in this thread seems to be that we want a minimalist approach of either a clickable element or radio buttons with minimal text. 

We all look at this display for many more hours than Squad devs do. Why not consider what the community is suggesting rather than shove an unpopular design down our throats and hide behind words like "Affordance" as the reason?

Edited by Tyko

Share this post


Link to post
Share on other sites
Posted (edited)
24 minutes ago, Tyko said:

Why not consider what the community is suggesting rather than shove an unpopular design down our throats and hide behind words like "Affordance" as the reason?

I'm not sure that's entirely fair. Clearly, from my previous posts in this thread I agree with your assessment of the use of space in the altimeter design, but I don't think Squad is hiding behind anything. Affordance was only one of at least four different considerations that Maxsimal gave for their design process which also included allocating development time, player familiarity, flexibility for different languages, and consideration for screen resolutions and visual impairments.

Now I don't know how much time and effort in programming is required to redesign that interface, but the current Squad development group inherited this design from previous developers that aren't around anymore. I doubt that there is anyone left on the design team that had a hand in creating that UI layout. The current guidance among this dev team seems to be to favor layout consistency first, supplemented by optional and unobtrusive additions. And Maxsimal DID explicitly say that they ARE considering community feedback. I think that's reasonable considering that this instrument cluster was intended to be a quick glance display. Many players could be frustrated if things weren't in their familiar places at critical moments.

Having said that... I agree with almost every issue you pointed out in your post and I personally wouldn't mind a little streamlining.

Edited by HvP

Share this post


Link to post
Share on other sites
1 minute ago, HvP said:

I'm not sure that's entirely fair. Clearly, from my previous posts in this thread I agree with your assessment of the use of space in the altimeter design, but I don't think Squad is hiding behind anything. Affordance was only one of at least four different considerations that Maxsimal gave for their design process which also included allocating development time, player familiarity, flexibility for different languages, and consideration for screen resolutions and visual impairments.

Now I don't know how much time and effort in programming is required to redesign that interface, but the current Squad development group inherited this design from previous developers that aren't around anymore. I doubt that there is anyone left on the design team that had a hand in creating that UI layout. The current guidance among this dev team seems to be to favor layout consistency first, supplemented by optional and unobtrusive additions. I think that's reasonable considering that this instrument cluster was intended to be a quick glance display I can see how many players could be frustrated if things weren't in their familiar places at critical moments.

Having said that... I agree with almost every issue you pointed out in your post and I personally wouldn't mind a little streamlining.

haha...I agree with you and I'm not asking for a redesign of the interface. I'm just asking for a minimalist approach to the ASL/AGL change, as I think many are. My point was that there's no "common design language" or "consistency" they're trying to match.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.