The answer is no to all of that. You can put an invisible button on top of everything to suppress the single tap for the menu but other than that, it is what it is.
This is a bit of a workaround, but if you create an invisible overlay (not multi-object state) that fills the entire page but otherwise does nothing (e.g. empty non-interactive HTML in a page-sized frame), you will be unable to swipe to another page.
But then you'd be locked out of all the other interactivity too. Hmm.
These changes to the ui would be essential for creating better experiences
for non-magazine stuff. I strongly support your requests.
with that adobe dps would fix many of the complaints from industry,
technicans and thinkers.
Thanks, I guess I knew that it is not currently supported.
Don't get me wrong, I love this platform and it's potential, but as a UX designer want to point out what I feel are some very easy common sense changes that would offer designers more flexibility, and improve the platform's overall user experience.
I just want to register this request again, since I feel it is important. And to ask if anyone has a workaround other than the "invisible button" trick.
I should point out that the "invisible button" trick works only intermittantly, it fails to work on certain interactive elements like 360 degree viewers (from our Crankamacallit app below), and of course on any inline HTML elements, of which we have plenty. So single tapping on these elements will invoke the menu. Add to this that some interactive elements REQUIRE a single tap to become active, such as slide shows, and the result is UX confusion and constantly popping up menu system that was invoked inadvertantly.
In the end this causes a very inconsistent user experience.
if you are really desperate to disable horizontal swipe, you can put huge object on your pages that will catch the horizontal swipe, like a pan and zoom. and put a transparent image in it wich is just a pixel wider than it's container. That will catch the swipe and will not swipe the page in the end.
Your interactive buttons can go on top. However, you can swipe using the buttons.
Great tip, thanks Johannes!
Do you think this will this cover up HTML elements too?
I have played with this, but this children's book app is so chock full of interactive elements, I just could not get this to work consistently.
Check out the video / demo reel, you can see what I'm dealing with: http://www.polymash.com/crankamacallit (video at the bottom of the page)
This project was about 60% development, 40% work arounds.
As I understand it, this also covers HTML webcontents. The important thing
is, that is has to be scroll-able, so content needs to be wider than the
A pan-only-overlay is just a webpage generated by indesign, displayed in a
This catches horizontal swipes and keeps them after reaching it's own end.
Not for vertical swipes: when the end of an HTML file is reached, any
additional swipe will trigger the next-page-event.
I articles in my magazines where the reader basicly hits a "dead end"
article, where he cannot swipe along to get to the next article.
The desktop previewer is behaving differently. So this sounds more like a
I know your crankamacallit. It is awesome how much workarounds you put in
there. I just hit everything to see how you did this and that ,-)
Well, you're the master of great tips and workarounds! Much appreciated, I will play with this!
And I do hope Adobe will respond to community requests to give designers greater control of the navigation system in the viewer, it would improve end user experience tremendously.
Has anyone tried this lately or come across a new work around? I tried several methods with buttons and underlying objects and it always swipes.
I would like users to be stopped at the end of an article where I have some navigation buttons taking them to another article, back to the index, or to the library. I also want readers to not be able to scroll "back" from the first page of each article. We are creating apps for collections of stories and they are not sequential.
Me too. I really think that if we create nav buttons and suppress all kind of effects like horizontal swiping and vertical bump effect it will greatly enhanced the usability. During our tests many people are confused what they can do and where are they going in the app.
I like a lot of the suggestions in here. But in thinking about what the tools can do, could you create the entire book as a MSO and then load that onto one page? Then you wouldnt have multiple pages, and you could create MSO navigation buttons. I dont know the extent of what is on your pages but it was just a thought.
Also think this is a great idea. What was the final verdict here? was the work around successful?
I have a similar situation here. I tried putting transparent PNG in a container and turned on scrollable frame but I can still swipe to the next page....Not consistently but still swipes???
Well, what if you create the entire page as a scrollable frame ie. paste all of the content into another frame (which is the same size as the page) and create a scrollable frame overlay, then upload the article as a PDF, the swipe to next page won't work (I've been having your problem in reverse!). You could then have navto buttons inside the scrollable frame to navigate. Just a thought...
Incidentally, I know that the swipe to next page is a problem with scrollable frames when uploading the article as a PDF, and the workaround was to upload as PNG, but this doesn't seem to work either. Anyone else having this problem?
Ok I guess that works...except that it covers up the pinch and zoom scrollable content that is apart of the design....Hmm wonder if there is a layering solution?
in the v22 webinar I saw a little glimpse in the layout of amit Guptas
folio saying "User:Interaction enabled", so there might be somehow a
feature later — but that's a bold rumor.
Is there an updat on this? Now in v23 can we disable page swipe?
No, it isn't available in v23 and likely won't be added in the next few releases.
interactive elements, such as scrollable frames no longer seem to be "dead spots" in terms of swipe navigation in a PDF format. Though when you zoom into text that has no fill in the text box, this changes to a white background as soon as you zoom which does not look pretty. This is V23 by the way.
I am also having the same issue as mobly, has anyone had any breakthroughs or updates recently?
I also would like to request a feature to disable horizontal/vertical swiping so that developers can use their own navigation. I agree that this feature is essential for developers using DPS outside of the magazine/publishing industry.
I'm going to throw a spanner in the works! I create quite a lot of non magazine style apps, and don't mind the swipe to next page!
Still I can see it could be useful for some :-)