beik

Hey @fulgur, thanks for taking a closer look! I will try to answer each of the questions below: This design replace the Crew portraits by a Video feed concept. It means that you will always have only one square element on the same position. I will add some detailed design later, but this is the plan: I like this idea because it add more useful "portrait", but still can display some IVA drama. And it adds a "eye" for probes too. If you want a list of the crew, you should have it after hitting "EVA". Makes sense? I decide to remove the G-meter from the main control because it's usually only relevant on ascending/reetry, right? The core idea is that the UI adapt for the context and don't display info that isn't relevant on premium places. For those who plays with G-force enable, I expect that you can still customize the ui by adding a small g-meter, and use a warning overlay for when the g-force is exceeding safety limits, like thermal problems, but below the top bar. The only thing that I'm not sure that would work is how to display crew specific information, not just vessel info. ¯\_(ツ)_/¯

More update on the redesign project! I'm still finishing the rational documentation behind this project, but I will share the draft. --- Experiment on a Flight HUD redesign (draft) My vision for KSP Learning by accident. Player profile Affinity matrix: Gammer x Aerospace Engineer (simplistic framework for analysis) Framing the problem Most UI suggestions rely on adding more elements to the screen to support a specific type of gameplay. It solves a lot of problem for hardcore KSP players, but they overload new players with information and complexity. Having a less enjoyable first-time experience hurts the KSP vision. The proposal Making a Flight UI that at the first time feels simple, but can progressively add more complexity. The idea is to adapt the controls/readouts by context, so you don't have to display information that isn't relevant to the actual player task. By adding controls mode that has an automatic context switcher, you can deliver a simple/walkthrough experience for new players and give contextual hooks for experienced players to add whatever they need. To support the control modes idea, I introduced a split control/planning concept, to offer a better interaction mapping for the changes. My vision for KSP Learning by accident. Player profile Matrix: Gammer x Aerospace Engineer (too shallow?) Framing the problem Most UI suggestions rely on adding more elements to the screen to support a specific type of gameplay. It solves a lot of problem for hardcore KSP players, but they overload new players with information and complexity. Having a less enjoyable first-time experience hurts the KSP vision. The proposal Making a Flight UI that at the first time feels simple, but can progressively add more complexity. The idea is to adapt the controls/readouts by context, so you don't have to display information that isn't relevant to the actual player task. By adding controls mode that has an automatic context switcher, you can deliver a simple/walkthrough experience for new players and give contextual hooks for experienced players to add whatever they need. To support the control modes idea, I introduced a split control/planning concept, to offer a better interaction mapping for the changes. (side note: This redesign doesn't focus on game elements, such as contracts and currencies) Conceptual map/wireframe DRAFT wireframe draft: https://imgur.com/j3AoZ0K conceptual map: https://mm.tt/1315215313?t=MHaz394g4C # Visual design overview DRAFT (those WIP were exported for a contrast check. As you can see, not perfect ) # Controls variations (work in progress, check conceptual map) # Advanced panels (work in progress, check conceptual map) # Customization (work in progress, check conceptual map) --- If you see something off, I would love to get early feedback

Okay, here we go with some more updates! I will finish the design details later and add proper introduction/racional behind every decision... But I'm too tired to do it right now... 1. Conceptual wireframe 2. Testing holographic-and-fun style, getting closer to KSP2 3. Why there's so little info on the screen (hint: adaptive based on context instruments/readout) I think it's hard to understand without a good documentation/demonstration, but I like to share WIP shots

I will finish a new wireframe tonight! I'm leaving a lot of space for mod tabs and customization

+1 I would hate to have to add bootcamp again

Anyone can help me with the list? 1. Throttle 2.Yaw/Roll/Pitch 3. Navbll 4. ??? 5. SAS direction 6. Stability assist 7. SAS/RCS toggle 8. Speed reference (???) 9. Speed + G-force (???) 10. Timewarp (???) 11. ??? 12. Altitude + Atmo (???) 13. ??? 14. Fuel/Resource (???) 15. Staging + dV

Hold by beer

As promised, some WIP based on the discussion in this thread Wireframing the main idea on a flight HUD revamp Slowing adding the details of each section

@Noir My feeling based on what I learn from the replies is that a catch-all instrumentation is the real problem. I will try to draft a new concept that split the UI in these blocks: Control mode (based on actual task) Space mode – Similar to the default solution Navball: The one we have today Secondary instruments: Small adaptations based on Atmospheric navigation, Vacuum navigation, Vessel encounter and Landing Air/Surface mode – Adaptation for Airplanes and Rovers Navball: Slight changed to reflect more vessel direction and roll compared to the surface Secondary instruments: More focus on waypoint navigation than orbit, Trim for planes, and Acc hold for rovers, Maintaining altitude Docking mode – Like the modsss Navball: Change to docking port camera, with proper port alignment Secondary instruments: Focus on an easier to understand WASD+IJKL maneuver, Monoprop resource Map, planning and resources Group things that are used for mission planning or critical for long term success, like: Settings targets Adding maneuver nodes (and refining it) Estimating resources and necessary delta-v Mission control communication Maneuver execution Group things that are related to time-sensitive actions: Pointing vessel to the right direction Warping to the right time Executing the burn for the right time Working antenna Crew, science and scans Group things relate to the Kerbals and activities (manned and unmanned): Manned – Dramatic portrait, Specialization, G Force and Start EVA Unmanned – Scan as "portrait" Crew/Sounding report, Science collected Apps and toolbar Group all apps by these modes: Simple button, Simple dropdown, Mini-hud, Modal overlay and Sidebar overlay (combinable) Actions/Readouts app (mini-hud and modal overlay) Customizable app that manage action parts Customizable readout, KER style Message app Group textual messages related more to the game aspect than the simulation. Game messages Contract information Mission log Help app Combination of learning resources KSPedia Contextual information, keyboard keys Real world knowledge Generic app (and mods) ... --- This is still a work in progress, but let me know if it sparks any new ideas

@mattinoz I started divided by the idea to just reskin or make radical changes. So I started redrawing everything so I could have the visual elements to play around. Everytime I decide to go for a change, it always had a number of implication in the UI and some lack of knowledge on my side (5yr playing Kerbal, had to google what that small triangle does in the altimeter). In the end I was too tired and decide to share it like this. To be honest, most of the people here have so much more knowledge than me that now it even feels silly for me trying to redesign this. --- @Noir What an amazing work! I will make a another version based on your vision <3 Let me comment some of your ideas, but feel free to trash me. Yes, I have a love/hate relationship with them. It makes sense in a way that it doesn't touch too much the rest of the UI... And that's is key to delivering changes that actual happen. For me it's tricky to "fix" because the "Maneuver mode" lies between flight/map mode, so it's not a Mode at all. Maybe it makes way more sense to group node with time, and split reading info from input change. Agreed, but the downside with KER approach is to scary new players. My girlfriend closed KSP after I told that the success for a good launch is to understanding what delta-v is. I found hard to decide this. The toggle feels hacky, so I just tried to improve the affordance. My UX background tells me that this should be adaptive. You don't need to know the ground distance from the space, and you don't have to know the sea level if you are going to crash. This logic probably doesn't work for everyone, most notable for the airplane lovers. You are right, the number aren't that important. I decide to keep it a bit big, so you still could have a place to drag it around... But a better solution would be to have a handle on hover event. The STAGE button doesn't exist, I added for the newbies! So people can have first-time fun without knowing any keyboard key. Does anyone use it? It feels like a totally legacy readout. For me it worked like a "you messed up" meter when I was learning how to fly. The only justification for something that big is that it adds a lot to the vintage physical interface style of KSP. I don't remember if the G force can affect individually passengers, if not, a single readout close to the portraits would make more sense. The only justification I see to keep it next to the navball, is because it relates to the amount of throttle. There's a funny thing in humans, that after you see a good ideia, is impossible to unsee it. Moving the Kerbals to a vertical stack with proper info is definitely one of them. Not sure why.. but yeah, how relevant is to look at the time all the time? (turumtumtrum tsss) To be honest, the time display could be better integrated with the warp. The way it is right now, it's mainly used by me as the Kraken notification display. How relevant is to have a shortcut for lights? Of course they look cool, but compared to Brake and Gears it feels silly. Agreed with everything, but the abort button. Moving to below the panel could risk it being clicked by accident, no? ¯\_(ツ)_/¯ The keyboard keys look cluttered, but I still feel like it have to be there somehow. It should draw the actual key/control on top, or some clever tooltips that disappear after some movement. But the catch is that KSP is pretty hard to memorize all the keyboard keys, and pretty unforgiving to let you press everything to see what it does during a flight. Yes, I'm talking to your RCS. When to you usually use trim levels? For planes or something hacky as ascend maneuvers? I did a quick research on how roll/pitch/yaw are represented near navballs, and ended at these: https://en.wikipedia.org/wiki/Attitude_indicator https://www.google.com/search?q=Flight+Director+Attitude+Indicator&tbm=isch&source=iu&ictx=1&fir=x16XYppmOJDzyM%3A%2CAeB7wtqxMbSQJM%2C_&vet=1&usg=AI4_-kR1RtB_CikdFVSQSR9nHSJfFkGw4Q&sa=X&ved=2ahUKEwiV9NDboYPkAhVWHbkGHVMfDlgQ9QEwAHoECAIQAw#imgrc=x16XYppmOJDzyM: (edit: https://en.wikipedia.org/wiki/Flight_instruments ) (edit 2: https://rocketry.wordpress.com/2012/08/21/manned-spaceflight-instrument-panels/ <- this! ) So the KSP solution isn't that off. But of course that doesn't mean that it can't be improved. So, let me know if you have more ideias stocked, I will try to work on this in the next week. Thanks again for the quality answer!

Nice catch! The idea was to reduce the stage-specific delta-v importance, to keep this as a readout for advanced players... but you are right, I totally overshot on this one. Thanks

I used Figma for this, it's kind of a online Adobe Illustrator made for UI work. You can even see the actual source in a webview: https://www.figma.com/file/09xWDTa5XQJy140q7sCyPX/Kerbal-–-Design-experiments?node-id=33%3A134 I would love to put out this as a mod, but I have no idea if that is even possible... I have only basic dev skills

I can picture a extremely sad designer having to generate bitmap asset with every possible key. lol yeah, you are right. It have to represent the actual keys somehow... but still, I like the idea to easy the process of teaching all possible keyboard keys

Hello folks! Based on the warm response of my last Experiment on a possible Tweakables Redesign (Result) , I decided to take another take on a bigger experiment! The idea was to redesign the Flight HUD, by polishing existing UI and respecting the original project (aka: don't reinvent everything). My approach was: Adjust the balance between skeuomorphism and flat design, adding a bit of texture but removing overused bevels effects. Improve usability by working on clear affordance. If you can drag, press, toggle... Differentiate it in a consistent way. More consistent iconography Easier learning curve for critical controls (staging as button, keyboard hints for throttle/roll/yaw/pitch) Add some small quality of live improvements (toggle solar panels/antenna, warp to next node) Better color mapping. Blue to delta-v, orange arrow for direct input, white arrow for readouts Flight HUD redesign In the end this looked like a very conservative approach, by keeping a lot of things in the same place... But boy, what a challenge! I had no idea that it would be that complex to redraw everything Things that I would like to improve: The action parts buttons could be better integrated, they feel a bit "meh" The app button could be better solved. I would love to see in the future something more iOSish, with a mix of mini-hud/modal/sidebar solution for the apps. I messed up with the font size. The raster version looks awful. Anyone uses the HDG reading? I hesitated to replace it with orbital info multiple times. I would love to add a "time to:" that adapt to hit ground/leave orbit/next maneuver Check the hi-resolution in vector format: https://www.figma.com/file/09xWDTa5XQJy140q7sCyPX/Kerbal-–-Design-experiments?node-id=33%3A134 What do you think?

Great suggestion! You have no idea how many hours interaction designers expend on the debate of UI slider. The trick is always to balance "precision" with "approximation by experimentation", but it's hard to have a silver bullet solution. Check this article to see how deep it can go: https://www.smashingmagazine.com/2017/07/designing-perfect-slider/

Lol, now I sound worst player than I really I'm. I was just trying to do some fine tuning to the port alignment, but in some axis Kermes was having a hard time to follow SAS directions. Probably I messed up something, but after the supply everything went fine. Thanks for the norma/anti-normal reminder, I'm going to stick to this Makes sense. My feeling was that even with all the different skills that you need, a couple of save-load during landings can get you a gold score. Thanks for the quick reply!

Hi @Mikki, just finished the mission... what a great adventure! You have no idea how many times I told my girlfriend that "I messed up in that part of the film that the big ship come back for rescue..." The concept for using dockport-as-lego blew my mind, congrats for the good work. Some questions... Kermes was kind of hard to maneuver for docking. Didn't manage to properly use RCS, and the wobbling made it extra hard. I had some problems with RCS maneuver on DreamChaser too... Is it planned to test my flight skills or I just need to get back to docking training? The idea that "time" doesn't matter was a surprise to my, because I tried super hard to make Dune encounters as fast a possible... And missed the delta-v to retrograde multiple times. It would be nice to know beforehand what counts toward fail/points. Talking about point, my suggestion is to add more hardcore mode. Easy could be the more forgiving, just follow the storyline. Medium could be the actual score system... that relies on precision. Hard could be time challenges or Alternative vehicles with less delta-v.

Hey @Poodmund, thanks for the tip! It warms my heart to hear that Squad actually care about design. Btw, I already applied a couple of days ago after a friend gave me the same tip. But I got excluded from the selection process because I don't have formal experience videogames design. It would be an amazing story to tell how 600 hours of playtime landed me a new job

Wow, this could be really helpful! We should definitely use this to hide info/actions that are too specific for a particular context. 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. 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!

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

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