beik

Members
  • Content Count

    23
  • Joined

  • Last visited

Community Reputation

119 Excellent

1 Follower

About beik

  • Rank
    Bottle Rocketeer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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. ¯\_(ツ)_/¯
  2. 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
  3. 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
  4. I will finish a new wireframe tonight! I'm leaving a lot of space for mod tabs and customization
  5. 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
  6. 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
  7. @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
  8. @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!
  9. 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
  10. 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
  11. 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
  12. 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?
  13. 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/