@Don L Not sure this what you're asking, but on the assumption you want to know if the "UPDATE" button is "intuitively obvious to the casual observer" as to it's intended functionality, here's my simple guess ... UPDATE is used to process any changes the user made to the Launch Conditions parameters (textfields in the Launch Conditions box) such that the associated graph is redrawn to reflect the changed data and, if a database is involved, update the data in that database as well.
Cheers Don, that's pretty much the purpose as confirmed by most other replies.
@Markus W Why have an update button at all? Why no live update?
I did think about it Markus, but I don't think live update is suitable in this situation.
There are too many variables and complicated calculations that need to be performed and checked. For instance, the Gross Weight cannot be less than the propellant weight of the motor (which is input in the previous window). For example, if the propellant weight was 60 grams and the user started typing into the gross weight input field, then an error message would keep coming up (annoying) - until they entered a number greater than 60.
For the purposes of "Lift-Off" of a Rocket, the entire weight (gross weight) has to include the fuel/petrol/gas/solid propellant/anti-gravity machine, etc. If that doesn't make sense, then it's time to look at something else.
Therefore, the best way to approach this was to force the user to select the UPDATE button. It's hard to explain without knowing the context and what's happening in the background.
Nevertheless, I do understand the point of using live update, which ironically I have used in the following example which includes one of the main variables of concern (Gross Weight).
The image below shows the previous (main) window. Near top/left there is "Gross Weight" (this IS using Live Update). If the user enters an incorrect value, then the background shows Red, ie. (error) also an (i) icon is displayed to alert the user to further information, and when selected, the resultant message is as shown.
This works fine because we only have three variables: Gross Weight, Propellant Weight, and Total Impulse from the loaded graph (motor). But in the "Altitude Predictions" window there are too many unknowns to make "Live Update" workable.
(my apologies for the next part - a good strong coffee should help. Personally, a good shot or two of aged Scottish malt whiskey or a nice Bourbon should make things even more clear. Or even a nice cup of Tea with a Bex Powder and good lie down. It's up to you.
After rectifying the issue, as an example, the user now has further options, and the "Altitude Predictions" button is available. This is a "Step by Step" process where preceding steps are validated otherwise the user cannot proceed, except to quit the application or do nothing (or of course, proceed as directed):
The user can now select "Altitude Predictions" to get to this window:
One relationship/connection between the two windows is shown as indicated by the red line (Gross Weight). This is used as a "What If" scenario where the user can change that value in order to show: [RUN SIMULATION] which shows a simulated real-time graphic of the rocket taking off (yet to be worked on).
I'm not sure if anyone will understand what I've posted above. But as a Software Developer it's only "ME" that can fully understand the reasons/conditions/solutions. Perhahs no-one will ever really know. Regardless, the User has to "Use" the software application for it's intended purpose, in that, we can ALL agree upon. It's a game of compromise and tweaking to get the balance right.
@Tim J Also, why not set the Rocket Type (shouldn't that be Motor Type?) to a PopupMenu? I also agree that the "Update" button should be part of the main window and not part of your second grouping.
The Rocket Type is NOT the same as The Motor Type.
Consider it this way. You have a motor/engine in your car. The motor/engine is inserted into the surrounding body which we call a Car, and affected by aerodynamic forces. In this case, the rocket motor is inserted into a tube with fins and nosecone (model rocketry), or the motor is attached to a stick with a pyrotechnic header - which is also affected by aerodynamic forces and also includes gravity. So what I'm saying is that we can have "Car Type" and "Engine Type". They CAN be exclusive, but of course not in this scenario.
The graph shown in the "Altitude Predictions" window is a small rendition of the "motor" performance. That is, it shows thrust performance over time of the test motor, which is part of the whole solution. It does not show altitude prediction.
The next window (image 3) will attempt to show a real-time simulation of the overall performance of the entire Rocket (as if it was to be launched). The calculations will only ever be "theoretical" because the main unknown in this whole equation is the drag co-efficient. This can only be worked out if you have access to a good wind tunnel. Everything else is just math/theoretical, but there is no other way except to go by "theory".
A popup menu would not be as effective in this case. There are only 2 options and it's made clear. The user can select either, then select EDIT, and depending on the choice, the next window will show with limited options pertaining to that choice. I can't see a way to simplify that. I think it works well in my mind. It's going to take effort to make it work as I want in the application code.
It would make sense to have on this Forum a category/section where we can post issues and have discussions regarding the Graphical User Interface (GUI Design). Which is where this post has ended up.
I'll put it forward under "Forum Issues". I really think it's very worthwhile.