Wishbone
Clueless developer
Unlike the multifunctional displays in real aerospacecraft, Orbiter's MFD's are small, as small as cellphone screens can be.
Unlike smartphones, smartpads and other smart hardware, MFD's cannot handle mouse input, will never use stylus/touch paradigm and have only 12 buttons. In real life, these buttons are supplemented with keyboards and other controls.
In this regard, I decided to write down my thoughts on what to strive for in MFD design, to fulfill the "practice what you preach" precept. This comes after some not so light reading on human-computer interaction, and as always criticism, comments and suggestions are welcome. (I reckon this post will be updated later).
1. Make the interface discoverable. While the three-letter abbrev may be less than adequate for that, at least try to choose word parts from which the player can intuitively reconstruct the name of the button. Always write the description of the button that is accessible through the MNU screen.
2. Group items commonly used together on a single screen.
3. Use pictures AND numbers to convey necessary information.
4. Design for color blindness. Unlike real pilots, Orbinauts don't go through the medical checkup and tough competition. Design for high contrast against a very light blue and white (Earth's disk) background.
5. Do not replicate the Shuttle's and Apollo's malpractice of entering cryptic numerical command codes (unless you're recreating the experience of Shuttle or Apollo).
6. Be consistent if you use several screens.
7. Try to minimize the nestedness of the screen hierarchy.
8. Always document all keyboard shortcuts.
9. Document all the functions and display elements. If there is anything that is "obvious" to you it is only because you have spent the enormous amount of time playing with the MFD. It is not obvious to others, not at all, thank you, sir.
10. If possible provide programmatic API for other add-ons to communicate with your MFD and for your MFD to do reverse communications with others (callbacks).
11. If you implement an autopilot, CUT ALL THRUSTERS and bring aerodynamic control surfaces back to zero when the MFD is destroyed or the world ends or whatever.
12. Don't CTD. Never.
13. Make sure your MFD works in other solar systems (where there is no "Sun", and no "Earth" bodies). Upsilon Andromedae looks to be a good test case for that.
14. Always store and recall and read and load the status of all user-defined and/or modified variables.
15. Do not store volatile computable on-the-fly values.
16. Why on Earth are you still using oapiDebugString? oapiWriteLog is much more convenient for debugging and gathering test reports from users.
17. Do not use locale-dependent string-to-number conversion routines. Use decimal point only for input.
18. TBD and to be continued...
Unlike smartphones, smartpads and other smart hardware, MFD's cannot handle mouse input, will never use stylus/touch paradigm and have only 12 buttons. In real life, these buttons are supplemented with keyboards and other controls.
In this regard, I decided to write down my thoughts on what to strive for in MFD design, to fulfill the "practice what you preach" precept. This comes after some not so light reading on human-computer interaction, and as always criticism, comments and suggestions are welcome. (I reckon this post will be updated later).
1. Make the interface discoverable. While the three-letter abbrev may be less than adequate for that, at least try to choose word parts from which the player can intuitively reconstruct the name of the button. Always write the description of the button that is accessible through the MNU screen.
2. Group items commonly used together on a single screen.
3. Use pictures AND numbers to convey necessary information.
4. Design for color blindness. Unlike real pilots, Orbinauts don't go through the medical checkup and tough competition. Design for high contrast against a very light blue and white (Earth's disk) background.
5. Do not replicate the Shuttle's and Apollo's malpractice of entering cryptic numerical command codes (unless you're recreating the experience of Shuttle or Apollo).
6. Be consistent if you use several screens.
7. Try to minimize the nestedness of the screen hierarchy.
8. Always document all keyboard shortcuts.
9. Document all the functions and display elements. If there is anything that is "obvious" to you it is only because you have spent the enormous amount of time playing with the MFD. It is not obvious to others, not at all, thank you, sir.
10. If possible provide programmatic API for other add-ons to communicate with your MFD and for your MFD to do reverse communications with others (callbacks).
11. If you implement an autopilot, CUT ALL THRUSTERS and bring aerodynamic control surfaces back to zero when the MFD is destroyed or the world ends or whatever.
12. Don't CTD. Never.
13. Make sure your MFD works in other solar systems (where there is no "Sun", and no "Earth" bodies). Upsilon Andromedae looks to be a good test case for that.
14. Always store and recall and read and load the status of all user-defined and/or modified variables.
15. Do not store volatile computable on-the-fly values.
16. Why on Earth are you still using oapiDebugString? oapiWriteLog is much more convenient for debugging and gathering test reports from users.
17. Do not use locale-dependent string-to-number conversion routines. Use decimal point only for input.
18. TBD and to be continued...
Last edited:
