Well I was going to use this to control a boat speed and rudder, but have noticed it moves in a circular path.
Which means when you turn left or right you lose the throttle value. 
Surely the joystick should move a square path, so that you can have full throttle while turningā¦
Itās intentional: SAFETY is the priority!
ā¦ Just kidding. But YES, it should be changed. But not really an error, maybe a design issue 
You can easily map incoming values so that certain vertical range wonāt affect the throttle. Same for turns.
I donāt think that would be a solution, imagine trying to manouvre and having to return the tiller to centre just to adjust the throttle, and vice-versa.
No, in order to use the joystick effectively, you have to have independent and simultaneous control of both the X and Y axes, just like the Throttle/Rudder and Aileron/Elevator controls on an airplane RC transmitter.
You can use 2 sliders then. Be creative
I did, works fine for controlling my AWESOME Blynk Powered Volkswagen T1 Transporter Hippie-de-Luxe van. 
I had thought of that Pavel, but there are going to be another 2 sliders on this project, and manipulating more than 2 at once on a small iPhone screen is just going to be cumbersomeā¦
Maybe Iāll give it a go and see how it pans out, but I do like the idea of controlling the boat movement with one finger, or a thumb ā¦
Well, rectangular can be put inside of a circle. Which means itās a pure math to map the values from joystick to do what you need.
Another thing against using sliders is that you canāt have Auto-Return to centre like the round joystick can have. This boat controller will have forward/reverse, and left/right, so āhands-offā would be straight and stop, ideal for the application, where accurate boat positioning will be the goal.
I like the idea of the rectangle inside the circle, Iāll have a think about the math involved, although I feel it would limit the usable range of the joystick control, giving 0-100% over SQRT(2) of the travel.
I truly believe that making and hacking is all about taking the tools and things you have, and adapt it to your needs.
Blynk offers various tools, and itās up to you and your imagination how to use it to achieve your goals. In this case - joystick fits your goals like 90%? Make the rest 10% by hacking it
And I truly believe that if I donāt have the correct tool in my toolbox, I go out and get one, rather than risk making something inferior, restrictive, or cumbersome to use.
If you are saying you are not going to consider making a square 2-axis joystick, where the two axes do not interfere with each other, then I will have to look elsewhere, and not use Blynk.
Sorry to hear that, but Iām just being transparent. We donāt plan to implemet square joystick in the nearest time for 2 reasons:
Well, Iām not using joystick and not planning to. I wonder how popular is this widget? For sure @Gunner uses it for his project. 
As ānot a userā I try to keep away, but still have a āright to voteā. Well there is one important (?) reason to change it to āsquare modeā: Almost every widget in Blynk emulates real world control devices (yet Iām not aware of any Zergba remote control ), but not Joystick. Thatās all!
2 votes counted then
Well as apparently as the unofficial āother user of this widgetā 
(I do use it for two different projects, a mobile rover and a Pan & Tilt for my PiCam) I should cast my voteā¦ however I have no strong feelings either way.
EDIT - OK, I re-read my post and I guess I do side on the āleave it as isā side after all 
)
I can see both sidesā¦ Yes, it ājust worksā well enough as is 
But in order to use the corners with full X/Y values, it would need to be a āsquareā.
As is, one can extrapolate it out with mathā¦ but I belive it would also require a reduction in resolution to account for the truncated values in the current ācornersā.
E.g. With a setting of -255 to 255 (leaving 0 as center) one can see how the round ācornersā prevent reaching full 255 values for both axisā¦ thus the device side math will have a reduced values to work with for extrapolation and more processing required for said math anyhow.
Howeverā¦ I feel that for most real IoT purposes, true corners and/or extrapolated resolution loss would be completely negligible, particularly for basic directional controls. I have found that anything requiring such motion precision probably shouldnāt be using a virtual interface anyhow as there is no tactile feedback required for such human interface precision.
I personally would prefer to see Blynk resources going to much more practical uses like a 4x20 LCD (OK, kiddingā¦ sorta 
)ā¦ actually more like graphical customisation of buttons, sliders, gauges with user supplied imagery to complement the built in options. Including a true image viewing widget - pulling data from the device/server as needed. And so on. But that is for another topic 
PS, I havenāt bothered to sit down and measure itā¦ but suspect that aside from the very fancy optically driven onesā¦ even physical joysticks based on potentiometers will run into a small degree of āroundā cornersā¦ these are analog devices based on physical limitations of rotationā¦ not square touch pads 
Also, I suspect that most precision controls never expect to be driven to the stops in any axis.
Actually they do the full scale (except some s*tyy ones, where I owned one some time)
Where I agree, is a low priority of this modification. But itās not the best design as it is currently
They can be closeā¦ but not physically possible to be stop to stop in a corner with dual pots and no mechanical āadjustmentsā that make the full x or y top/bottom out before full lever extension anyhow. Like a box inside of a circleā¦ only now the loss is on the sides not the corners.
Comparing analog with digital will always have digital āaveragingā to some small degree.
It is a dual lever design: One lever hinged to the other, which is hinged to base. That way one pot doesnāt influence the movements of the other. Butā¦ is it important at all??
Exactly the point 
ā¦ Aside from the intellectual debate of mechanical vs. virtual (which admittedly the engineer wannabe in me enjoys) arguments can be made either way, but for this topics OP, wellā¦ the widget just simply works for what it needs to do