Re: [Orekit Developers] [SOCIS 2011] usability

[Alexis Robert <alexis.robert@gmail.com>]

On Sat, Aug 13, 2011 at 5:47 PM, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:
> Hi Alexis,

Hi,

> 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:

Yes I understand there is too much clicks and it needs to be reduced.
That's what I wanted to work on just after finishing the events part
implementation :)

One way I was considering is that I would change the way orbits data
are entered : when you click on "Orbit data", you have a list of
parameters (like eccentricity and so on) and you need to click on each
item to have a DoubleDialog to enter the value. I was planning on
changing this list to become a more standard form, which will greatly
reduce the number of clicks.

The advantage of having separated selectors instead of having
everything on the main Orbit part form, is that it's very well
integrated with how the Android API is done, with Intents and so on,
and so it was very easy to re-use the "Date" popup or others in other
parts of the application. It's also very easy to maintain.

The thing which can also be considered is that screen 1 was made to
add a "Recently used orbits" separator with the 10 last used orbit
behind it (as well as a "Download TLE from the web" on the TLE orbit
details form) without cluggering the initial form.

I think one of the problem is that I've developed the application to
work well on phones, while checking if it works on Android 2.X tablet
screen sizes, and it may look more ineffective on a tablet because
there is a lot of free unused room. It's difficult not to have this
effect if you don't use Android 3.X APIs. But there is too many clicks
on Android 2.X too :)

There is a possibility of using a wizard, but that may need Android
3.X Fragments API (which can be backported on Android 1.6+ by an
official library), I'll need to study that.

> 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).

It's possible, it would rely on having custom views like OrbitView why
modify itselfs by adding an other CartesianOrbitView in its body when
you select a cartesian orbit, where you'll have x/y/z text fields, or
a/e/i/... if you select a keplerian orbit, all of them on the main
form.

This could be pretty nice and not so hard to make, but I don't really
see where you can add a "Recently used orbits" or add a "Download TLE
from the web" without cluggering the form (because it needs to render
on smartphones as well, where you don't have a lot of horizontal view
-- that's why the impulse maneuver says LOF and not Local Orbital
Frame, because there would be no room left for the "Not set" label and
the "Configure" button :) ). If you have an idea, I take it :)

> 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.

By the way, I originally wanted to change screen 1 to add the orbit
fields just under the "Orbit type ..." as soon as you selected it (and
that's why there is a clear(); method in SelectorActivity.java), but
OrbitSelector.java was beginning to be a huge mess and I added this in
an other form.

However, I was already not happy with screen 1 :)

> 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".

Hmm, why not, but how would you like to choose LOF type selection ?
Like adding on the top a bunch of LOF (LVLH) and so on ?

> 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.

Ok I see :)

> 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.

OK, I'll implement that as soon as I finish the events part.

> 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, ...).

OK, that's not very hard to make :)

Have a nice day,

Alexis