DroidPlanner / Tower

Ground Control Station for Android Devices
https://play.google.com/store/apps/details?id=org.droidplanner.android
Other
619 stars 554 forks source link

Follow Me UI #798

Closed jason4short closed 9 years ago

jason4short commented 10 years ago

Example UI for follow me.

follow_me

winstonsaz commented 10 years ago

Excellent interface, so I hope and look for the final version.

m4gr3d commented 10 years ago

@jason4short an edittext input box seems better for altitude, and radius input. It allows for more fine tuned entry, and minimizes the screen estate occupied by the -, + buttons.

jason4short commented 10 years ago

I don't want the keyboard popping up over the UI when changing altitudes. It's too modal and interferes with the workflow. I would love to have a more sophisticated slider input, but this was all that was possible after talking to Arthur.

m4gr3d commented 10 years ago

I disagree with the keyboard interfering with the workflow. IMO, if I'm about to change either values, I'd expect the process to be quick, which in most case means I'd be expecting a numeric keyboard to pop up. For quick increments/decrements, a dialog showing a number picker would be more in line with what to expect on an android device: Number Picker

Using that widget, the user can update the value by tapping up/down, scrolling up/down, or tapping on the number to edit it with the keyboard.

Either way, we should probably standardize of which type of widget is being used throughout the app to edit/enter numeric values. The slider input, while ideal in theory, ends up being a major pain (at least for me) when I'm using to set up a waypoint (i.e: altitude, radius...)

jason4short commented 10 years ago

The keyboard is modal and doesn't know you have finished inputting. It makes you hit the back arrow key to hide it which is not intuitive. It also partially covers the UI which takes you out of the flow.

An example is changing values in parameters. Today this is difficult for most users since the UI to send the value is hidden when the keyboard is displayed.

We looked at the spinner widget and would like to adapt a variation of it since it is very large vertically. Jason

On Jun 23, 2014, at 9:50 AM, Fredia Huya-Kouadio notifications@github.com wrote:

I disagree with the keyboard interfering with the workflow. IMO, if I'm about to change either values, I'd expect the process to be quick, which in most case means I'd be expecting a numeric keyboard to pop up. For quick increments/decrements, a dialog showing a number picker would be more in line with what to expect on an android device:

Using that widget, the user can update the value by tapping up/down, scrolling up/down, or tapping on the number to edit it with the keyboard.

Either way, we should probably standardize of which type of widget is being used throughout the app to edit/enter numeric values. The slider input, while ideal in theory, ends up being a major pain (at least for me) when I'm using to set up a waypoint (i.e: altitude, radius...)

— Reply to this email directly or view it on GitHub.

m4gr3d commented 10 years ago

Well the spinner widget can be 'rotated' so the up/down arrows become left/right arrows, and the scrolling is done horizontally, instead of vertically. That would take care of its large vertical screen estate, since it won't be any taller than the input (+ paddings).

If we use a 'rotated' spinner widget, we can keep the default show up behavior, which pops up a small dialog. This has the advantage we can customize the Done button based on the current screen. However, it still is modal like the keyboard.

On the other hand, we can integrate the 'rotated' spinner widget within the view. This way, users can click on the left/right arrows for minor increments/decrements, swipe left/right to scroll for larger value changes, or tap on the number itself for editing with a keyboard (if that's what a user want, then we shouldn't prevent that scenario).

m4gr3d commented 10 years ago

@jason4short any thoughts on the integrated 'rotated' spinner widget. I can update the followme ui on a separate branch to better highlight.

jason4short commented 10 years ago

pastedgraphic-20 A sketch I was working on a while back. Jason

keyoss commented 10 years ago

i miss the option to define the speed.. for circle, tic-toc etc in this case. you can define radius, alt.. but where to 'simply' define the movement speed? afaik its depending on a value set in parameters for now (nav speed). could this be changed/added to/with a decimal input?

Thalek commented 10 years ago

I like the idea of being able to define the speed for various functions, but have no idea as to how to do that. Is that because I'm looking in the wrong places, or because it does not currently exist?

squilter commented 10 years ago

It should adjust speed automatically to follow. That said, there are some parameters which limit the maximum acceleration and maximum speed while following. Those are in the parameters list. But I wouldn't recommend messing with those - the flight is usually smoothest at default values.

Thalek commented 10 years ago

I suspected the drone would only follow me at my pace, at least for the simple version of follow-me.

What about plotting a flight or plotting a survey? Way points that have the circle command embedded in them? Is the speed adjustable for any of those?

keyoss commented 10 years ago

@Thalek yes, these can be 'globally' configured by nav_speed in the parameters (for pixhawk). they can not be configured for each waypoint! (right now)

Thalek commented 10 years ago

Thanks! Unless I can think of a need, global should be enough.

arthurbenemann commented 9 years ago

The UI has been updated by #1125