Lately I updatet from floatbox 4.x to 5.7.1, and have to congratulate to the immense improvements made within over one year.

Especially the new inbox-zoom-function is great, but could be further improved by following thoughts:

1.) Incremental zoom:
As before in version 4, we can now zoom from the preview-scale to fullsize-scale. On very large pictures or very small vieports this is not optimal, since medium-zoom-steps are missing (e.g. having a very large worldmap, it is impossible to zoom just to a single part like a single continent if the scale means either viewing the whole world or a full-zoomed country). Maybe you or others have ideas if and how to make this most practical for mouse-users and touch-screens.

2.) Box-Dragging on images:
On 4.x, keeping the left mousebutton clicked on a (zoomable or non-zoomable) image would drag the whole box like clicking on the outside frameborder (if dragmove enabled). In 5.7.1 this is not possible any more: On single images, either nothing happens or the zoom is triggered; on gallery-sets, the new "sliding" function is triggered. This behaviour should be customizable by a setting, whether the sliding-function or the "old" possibility to allow moving the whole box by keeping the picture clicked is preferred.

Incremental image zoom has been on the maybe list for a while, but has never made it to either the do-list nor the graveyard of bad ideas. If implemented, and like all of Floatbox capabilities, it has to make sense and work well for both mouse and touch devices. Mouse implementation is fairly simple by tying the resizing to the mouse scroll-wheel. Touch is more complex. Zooming should obviously be tied to a two-finger pinch gesture, but this could be a challenge. If one finger goes down, should it be processed or is there a second finger about to touch down shortly after, and will this second finger participate in a pinch? Should we delay responding to the first finger to see if something else is coming? Delaying interferes with smooth and immediate response to single touch gestures, and in some circumstances risks invoking the browsers pop-up blocker. Once the pinch is received, decisions have to be made about whether the image can grow or shrink and whether the gesture should be passed on to the browser to zoom the entire page, which is what folks are usually doing when they pinch in a browser. The mouse-scroll wheel implementation also has the problem of deciding whether to handle the scroll in the floatbox content or allow the user to scroll the page with the wheel. These complications don't mean it can't be done, but do suggest that it will be a lot of work, will take a fair amount of code, and introduce some potential fragility. These considerations keep incremental zoom on the maybe list, and not yet on the do list.

Dragging on the image area, either with a mouse-down or a touch, has been given over to navigating to the next and previous items in a gallery set. Moving the box by dragging on the image is never coming back.

First to your last statement:

admin wrote

Dragging on the image area, either with a mouse-down or a touch, has been given over to navigating to the next and previous items in a gallery set. Moving the box by dragging on the image is never coming back.

From my point of view, that's a step-back from general usability. Concentrating on Mobile-Devices is good and important, but not if it slows down desktop-users unnecessarly (Microsoft also did this mistake with their "desktop-user-unfriendly" Win8-approach).

Imagine a non-modal multi-box setup, where you want to quickly arrange multiple boxes and are used to do this by just dragging the image - That went extremely fast and intuitive in v4.x. Also, it allowed minimal frame-sizes since you don't have to hit them directly. Now in v5.7.1, users are slowed down by pointing directly to unnecessarly thickened frames, just because there MAY be a gallery-set somewhere and MAY be a mobile-touchscreen user. There are already so many possibilities to slide pictures (inpicture navigation, left-right-arrow-buttons, keyboard, index), and so limited possibilies for dragging boxes (frame only). The latest gesture-add is a nice one to do so JUST for mobiles JUST in gallery-sets and JUST as an additional alternative to existing buttons, and therefor should be customizable by setting.

admin wrote

Incremental image zoom has been on the maybe list for a while, but has never made it to either the do-list nor the graveyard of bad ideas. If implemented, and like all of Floatbox capabilities, it has to make sense and work well for both mouse and touch devices. Mouse implementation is fairly simple by tying the resizing to the mouse scroll-wheel. Touch is more complex. Zooming should obviously be tied to a two-finger pinch gesture, but this could be a challenge.

I thought a little bit about that. As a classical and also mouse- and touch-usable approach could be two Zoom-Buttons (In /Out) inside the left or right frame-boarder. so one could fully zom by clicking on picture, or incrementally zoom by the additional buttons.

JK2011 wrote

and therefor should be customizable by setting.

I have to apologize for this one, since the setting enableSwipeNav already exists. I found this accidentially in the release-notes, but this seems to be not yet in the official Options Reference documentation.

Optimal would be setting enableSwipeNav:"mobile" to enable this only on mobile-devices,

and give desktop-users some kind of "enablePictureDragMove" as described before this post. Practical logic would be to prefer enableSwipeNav before enablePictureDragMove.

What do you think, could this be possible?

Alright, alright, I relent!

The next version of Floatbox can be moved by a mouse drag on image content. enableSwipeNav applies only to touch gestures. If enableSwipeNav is false and enableDragMove is true, the floatbox can be moved by touch gesture on image content.

Also, related to another thread, a running slideshow will pause on user input such as navigation or resizing.

No new options have been added, and none changed, to manage these behaviour changes.

admin wrote

No new options have been added, and none changed, to manage these behaviour changes.

Great approach! Many thanks!!