[Orekit Developers] [SOCIS 2011] usability

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

Hi Alexis,

I have played a little with the application. Here are some new comments.

Entering an orbit involve many clicks and separated screens. Could the  
number of screens be reduced or at least having some sort of wizard  
type behaviour, where completing on screen automatically brings you to  
the next one ? As an example, entering a keplerian orbit now implies:

 - selecting "Set orbit type ..." in screen 1, which leads to screen 2A where
   you select the type and then you automatically goes back to screen 1
 - selecting "Set orbit data ..." in screen 1, which leads to screen 2B where
   you see the parameters.

    - selecting "Semi-major axis ..." in screen 2B fires
                popup 3A for semi major axis, in which you still have to
                click to fire the virtual keyboard
    - selecting "Eccentricity ..." in screen 2B fires
                popup 3B for eccentricity, in which you still have to
                click to fire the virtual keyboard
    - selecting "Inclination ..." in screen 2B fires
                popup 3C for inclination, in which you still have to
                click to fire the virtual keyboard
    - selecting "Perigee argument ..." in screen 2B fires
                popup 3D for perigee argument, in which you still have to
                click to fire the virtual keyboard
    - selecting "Right ascension of ascending node ..." in screen 2B fires
                popup 3E for RAAN, in which you still have to
                click to fire the virtual keyboard
    - selecting "Anomaly ..." in screen 2B fires
                popup 3F for anomaly, in which you still have to
                click to fire the virtual keyboard
    - selecting "Set anomaly angle type ..." in screen 2B fires
                screen 3G where you actually select the type
                and then you automatically goes back to screen 2B
    - selecting "Select a frame ..." in screen 2B fires
                screen 3H where you actually select the type
                and then you automatically goes back to screen 2B
    - selecting "Set a date ..." in screen 2B fires
                screen 3I, which itself lead to screen 4A (time scale),
                popup 4B (date), popup 4C (hour), popup 4D (seconds) and you
                have to press OK to go back to screen 2B
    - selecting "Central attraction coefficient ..." in screen 2B fires
                popup 3J for semi major axis, in which you still have to
                click to fire the virtual keyboard

Would it be possible to have in-screen edition ? That would mean that  
for selections (like orbit types, angle types, frames, time scales,  
LOF frame types in maneuvers ...), we would simply the choice list  
would appear in a popup rather than a full screen (and use a standard  
graphical widget to show it is a choice, instead of a "Configure"  
button). For keyboard entries, we would simply have a cursor in the  
input text text field without changing screen. It would also be nice  
to have the orbit data fields in screen 1 rather than in a dedicated  
screen 2B. This would however imply that depending on orbit type  
selection, the labels would change (a, e, i ... for Keplerian, x, y, z  
... for Cartesian and so on). For this later change, you may consider  
using anonymous arrays to retrieve the parameters from the graphical  
interface and use the mapArrayToOrbit method from OrbitType, which  
builds an orbit of the right type.

Typically, the screen for impulse maneuver is much more compact as it  
displays everything at once. It would be nice to achieve a similar  
result for orbit.

The current frame selection for impulse maneuver has one setting for  
Local Orbital Frame and another for "other" frames. It would be nice  
to have everything gathered in one choice list, probably with the LOF  
frames on top and the other frames on bottom. The label "Increment  
frame" should also be changed to "Maneuver defining frame".

The label "Engine impulse" should be changed to "Specific Impulse".  
This parameter could also be completely hidden for now and replaced by  
an arbitrary constant (say 400s). It corresponds to the efficiency of  
the thruster and is used to compute the propellant consumption to  
achieve the specified velocity increment. As we don't (yet) set  
spacecraft mass we are not (yet) interested in the consumed propellant  
mass. A better alternative would be of course to keep this parameter,  
but then we should also have an entry for spacecraft mass before the  
maneuver, and we would display as a result both the spacecraft mass  
after maneuver and the consumed propellant mass.

It would be nice to have the output orbit after maneuver be displayed  
in the same representation as the input maneuver (i.e. Keplerian of  
initial orbit was keplerian ...). This can be achieved with the  
following code:

  Orbit initialOrbit = ...;
  Orbit finalOrbit   = computeSomething(initialOrbit, ...);

  // at this step, initialOrbit and finalOrbit may have different types

  // force type of finalOrbit to match type of initialOrbit
  finalOrbit = initialOrbit.getType().convertType(finalOrbit);

For now, computing a maneuver on a Keplerian orbit provides a result  
as an equinoctial orbit.

Once input and output orbits are of same type, the result could be  
display both as the final orbit as it is now but also as elements  
changes (i.e. Δa, Δe, ...).

best regards,
Luc


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.