Closed jason4short closed 9 years ago
Excellent interface, so I hope and look for the final version.
@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.
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.
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...)
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.
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).
@jason4short any thoughts on the integrated 'rotated' spinner widget. I can update the followme ui on a separate branch to better highlight.
A sketch I was working on a while back.
Jason
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?
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?
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.
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?
@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)
Thanks! Unless I can think of a need, global should be enough.
The UI has been updated by #1125
Example UI for follow me.