Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Follow Me UI #798

Closed
jason4short opened this issue Jun 9, 2014 · 15 comments
Closed

Follow Me UI #798

jason4short opened this issue Jun 9, 2014 · 15 comments
Assignees

Comments

@jason4short
Copy link
Contributor

Example UI for follow me.

follow_me

@winstonsaz
Copy link

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

@m4gr3d
Copy link
Member

m4gr3d commented Jun 23, 2014

@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
Copy link
Contributor Author

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
Copy link
Member

m4gr3d commented Jun 23, 2014

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
Copy link
Contributor Author

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
Copy link
Member

m4gr3d commented Jun 23, 2014

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
Copy link
Member

m4gr3d commented Jun 24, 2014

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

@jason4short
Copy link
Contributor Author

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

@keyoss
Copy link

keyoss commented Sep 9, 2014

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
Copy link

Thalek commented Sep 9, 2014

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
Copy link
Member

squilter commented Sep 9, 2014

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
Copy link

Thalek commented Sep 9, 2014

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
Copy link

keyoss commented Sep 10, 2014

@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
Copy link

Thalek commented Sep 10, 2014

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

@arthurbenemann
Copy link
Member

The UI has been updated by #1125

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants