[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] [SOCIS 2011] usability

Alexis Robert <alexis.robert@gmail.com> a écrit :


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 :)
OK. If you prefer to go with Android 3.X, you have my green light to do so. Are there many devices that are already shipped with this version ? 



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


I understand. I have no ideas ...




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 ?
In fact, there should be no real difference between LOF frames and any other frame from a user point of view. From the application point of view, there are two enums (LOFType and Predefined), so depending on what the user choose, when we need to really build the frame, we either use FramesFactory.getFrame(predefined), or new LocalOrbitalFrame(orbit.getFrame(), loftype, propagator, loftype.toString()). 




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 :)
Here is another problem I encountered. when I attempt to frame conversion between EME2000 and one of the ITRF frames, I get an error: « unable to find file /META-INF/IERS-conventions-2003/tab5.2a.txt ». In fact, this file is an internal resource of the library and should be embedded in the Orekit jar, and we use the Java standard getResourceAsStream to read it as it is in the classpath. Did you build your own jar without this file or is there a problem loading resources from the classpath in Android ? 

best regards,
Luc



Have a nice day,

Alexis






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