We recently published a children's book using the Adobe DPS suite. We've had great feedback for the most part, but several professional app reviewers had several usability issues with the platform, specifically the menu system and sensitivity of swiping from side to side to go through pages.

They were kind enough not to give us a review at all, since it would have been negative from their perspective.

They stated that if we were to fix these technical issues, they would give us an excellent review.

Having spent a lot of money on the effort, reviews from pro sites like 148 apps are critical in making apps and magazines commercially successful.

So, my questions to Adobe (some of them repeats from last year's pre-release program)

Can side to side navigation be turned off, enabling the developer to control the navigation in a .folio?

Can the way the menu system is invoked be altered? Some ideas:

press and hold to invoke the menu

double tap to invoke the menu

reserve an area (top left, for example) for invoking the menu

anything BUT single tapping, since IMO this is the gesture should be reserved for interactive elements, not core navigation.

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.

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.

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.

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.

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?

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 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.