I'm not sure what's happening here. I've got a page with a scrolling frame which covers the whole page, frame is set to scrolling, scroll direction is vertical only. I've just updated some of the scrollabe content and now when I view on iPad I can't swipe to the next article, the swipe to next article worked fine yesterday, all content and links work OK I just can't get off the page now... any suggestions?
Well I went back a stage and rebuilt the file bringing back each element in turn but can't reproduce it. I'm glad my workflow setup seems to be working.
I'd still be interested to know what it was if anyone experienced anything similar, the gesture felt ultra sensitive, allowing a swipe horizontally only with real effort.
You're making a horizontal only folio? with a full page scrollable frame?
one direction or both directions?
if you import the article into the folio as a PNG ARTICLE you will be able to swipe off it.
you do know you can make smooth scrolling pages?
Change the article height to over 768px or 1536px depending on which ratio you're designing to, then when you import it select Horizontal in the smooth scroll drop down...
This removes the need for a scrollable frame...
You can set your folio to be PDF by default, but then import certain articles as a different format, which is why I was suggesting for the pages with scrollable frames to import as PNG.
Does all this make sense?
But still tho, the point is valid.
With a scrollable frame that only scrolls vertically, shouldn't one be able to swipe to the next page?
I encounter this problem quite frequently with small scrollable parts of a page. I see many users having problems with this, when they want to swipe to the next page. The workaround I've found is to have clear pointing arrows placed somewhere else on the page saying "Swipe to the next page" or similar, but obviously it would be nice if that could be omitted.
Wouldn't it be an idea to allow page swiping on vertical-only scrollable frames?
Apologies, I realize I mis-spoke. Sroll in one direction only (horizontal). I worry about the PNG import, as I understand that does not render as sharply in retna/ iPad 3. But maybe if the folio is pdf and the individual articles are png, that does not hold true?
I wonder if I can use your adjusted page height idea in a different way -- make my pages all really wide. I'm going to give that a try.
Bob Levine wrote:
I'm going to nit pick a little bit here:
Change the article height to over 768px or 1536px
That should say 768 or 1024. I just don't want some to be confused reading this.
Nit Pick all you want Bob - but get your facts straight first.
My understanding before this was clarified three posts after your "nit pick" was that this post was related to a Horizontal only article.
therefor the height will always be 768px or if you're going to go for iPad 3 Dimensions then your height would be 1536px.
If you're going to start slamming people on a help forum.
make sure you do it right.
So your folio is of Vertical Orientation?
I have tried the horizontal smooth scroll, it wouldn't work for myself but maybe you'll have better luck!
Don't worry about the quality, it still looks really good on the iPad 3 if you have good quality assets!
I've been mixing png and pdf pages for a while now! and it seems to do pretty well!! doesn't really make a difference to over all folio size either!
As I said before, Good Luck with the smooth scroll pages!
My folio is horizontal-only orientation with horizontal-only, full-page scrolling frames. So the interactivity couldn't tell the difference between the user scrolling page content, or attempting to swipe to the next article. Sorry for the confusion.
Thanks for all the brainstorms/ideas for workarounds. If I come up with a good solution, I'll post here.
And that’s my point. You should only be designing at 1024x768. Creating a file that is 2048x1536 is unnecessary and prone to problems.
Create it at 1024x768 and set the folio resolution to 2048x1536.
I've managed somehow to get the same effect discussed initially here on the same document, again whilst updating copy within the scrolling content.
I've set my folio as jpeg, articles are jpeg, my scrolling content is 1024 x 4000px so pdf wouldn't work here. The document layout is quite simple. One super overlay at the top which has some simple graphics and some instructional copy. Under this overlay is the scrolling frame covering the whole page space. I've 'pasted into' the scrolling content into the scrolling frame, set frame to scroll vertical only.
There is a marked difference in ability to swipe to the next article (horizontaly) between the two end results, one is almost impossible without multiple attempts, the other is a simple normal gesture and easily activated. Reproduces on both iPad 2 & 3
I still have no idea what's causing and this time I can't seem to get it back the way I want it. I've deleted article from folio, rebuilt article and fresh import to folio to no effect, could it be asset related, naming or something in that area? I'll try re-building scrolling content to see if I can find anything..
OK, thanks for letting me know, I thought there was a 2pg limit but appreciate this must be article related, not scrolling content related.
So, format aside then as it's 'not' pdf... I still can't swipe to next article even on the super overlay, this is easy stuff to do, something is happening to the ability to swipe horizontally.
Any other areas worth digging into?
I wanted a scrolling content page (it's a 1024x768 landscape only folio) so have set a single page up with that content in a scrolling frame.The page has graphics on the background (under the scrolling content) which stay static. The scrolling content has transparency in places so you can see the underlying graphics. The static super overlay at the top of page has instructions and additional graphics which the scrolling content scrolls under.
Is there another way to get the same effect?
Still can't work out why this flipped out, it's been fine until last Friday when this gesture glitch started. We've had many people look through it to test, non ipad owners for testing too and they felt it easy to grasp and navigate.... now it's just impossible.
I haven't changed anything in the article or folio structure/preferences. I've only editted text within the scrolling content.
Ah I think I understand you now.
So you have a scrollable frame that is 1024px wide and 4000px high
that sits within an article that is 1024px wide and 768px high.
Your scrollable frame is set to Verticle Only but you still can't swipe horizontally to the next article.
> Try and import this article as a PNG - I know you've tried JPEG, but I've only managed to get these types of articles to work as PNG
which is a credit to Bob, because he suggested this a few months back on a post I was having trouble with myself...
PNG should work
Another issue might be the size of this thing. I’m not sure what the current recommendations are but it wasn’t that long ago that anything over 2000 pixels was a crapshoot as far as problems are concerned. I think most of that was memory issues, though.
Excuse the lame design (only 10 minutes of my lunch break left)
So I quickly mocked up a 768x1024 doc (Horizontal)
Made a Scrollable frame 732x952px to sit on the page bleed at the bottom and within left and right margins
Created 4000px Deep worth of fake content (Grouped and pasted into the scrolling frame)
Set to vertical scroll only
Popped a stickly overlay on top and a background image underneath
All in seperate layers.
Imported as a PNG article
and here are the results.
All images are screen grabs and the last demonstrates that even with a scrolling frame this long - if you import as png you can still horizontally swipe off it
After upgrading to V19 we were unable to swipe to the next page over any scrolling content. However when the app was published it worked just fine. Leap of faith I call it! So when testing anything using content viewer (desk and tablet) the scrolling content areas remain dead yet when the app is published everything works just as it should.
Thanks for testing Tim, really appreciate your time, esp over your lunch ;-) I was thinking size maybe the culprit too but ...no joy as png!! Deleted article and made new as png, still has the same ultra sensitive feel.
The swipe works (with effort) when the scrolling content is butted against the frame edge (either top or bottom) giving the user 'some' edge to hold the content against whilst swiping to keep registration but when it's in the middle of the scrolling content it's like subtle small movements of the content is stopping the swipe but it wasn't this sensitive before.
Going to have to look at re-building it I think, it's got to be quicker than trying to find what the issue is.
Thanks Yellow, your braver than me! How would your users navigate if the page ended up dead?
I'm actually building a contents page which was a late addition to the folio and came from early iPad users not aware of navigation functions, there's also big navto links over images throughout so users can get out easily, I'm wondering whether to include the article now though ;-)
Was there any discussion here when you were testing troubleshooting?
It does work. Published two successful folios since the v19 upgrade. All of which wouldn't let you swipe over any scrolling content, regardless of real estate, when tested with the viewer. In the viewers defence it's the only problem I've discovered with it. DPS is not an exact science, more of a dark art!
Hugo, yes I think MOBLY started a thread about dead space over scrolling content when v19 came about. You'd have to dig though. I've been using DPS since pre-release (where you could swipe over scrolling areas when testing in Viewer). The leap of faith wasn't quite a big leap! We have a sandbox account and published to these credentials so only a set amount of devices could subscribe to it, and it behaved differently. In a good way. Full page slide shows were always the sticking point but with hot spot activation thats not really an issue anymore.
Thanks Yellow, in a funny way it's reassuring that the road is well trodden with DPS. It has been a mind field at times. I've gotten most, if not all my help from this community, including yourself in some instances. I looked at the tools in pre-release and registered etc. but my workplace took their time in appreciating how fast change was happening. Anyway here we are, and this is my first release (first of many I hope) with quite a lot of vested interest now. I'll look up Moblys thread, the name's very familiar.
If of interest to anyone here's my solution, or the problem, whichever way...
I couldn't work out why i couldn't swipe on the super overlay so I moved the top edge of the scrolling content frame that used to fill the whole page and sit under the super overlay, pulling it down (about 100px) from the top but still kept it just hidden under the lower edge of the super overlay as that was 400px from the top of the page but runs across the width of the page. Updated article and it now works as before.... mind boggling... 3 hours to find and only 30 seconds to fix. And yes there is a definate difference in ability to navigate out of the page.
Was it something to do with the scrolling content covering the super overlay even though it was below?
..back to work!
Scrollable frams supercede any other function. You need a safe area somewhere to be about to swipe vertically or horizontally, otherwise you are just swiping inside of the scrollable frame. I have come across professional publications that have a full frame scrollable page and you can not even get to the next page without using the quick scrubber or the table of contents. This is an issue that I still deal with regularly. Good luck.
Hi team - rediscovered this thread having had similar problems. I have an additional tip I have discovered.
I have a series of articles, each made up of a scrolling text box containing anchored artwork on a vertical layout. The scrolling text box takes up around 90% of the page - with a thin running header above it.
I found I was unable to swipe right or left to the next article on some of the pages, but not on others. To clarify, the template is exactly the same for each page. So why the difference?
What I discovered was that on some of my scrolling text boxes, anchored artwork carried drop shadow or outer glow that caused it to sit fractionally outside the confines of the text box in which they were anchored.
WIth the shadow removed or the artwork adjusted so that every part of it fitted within the frame, hey presto! Everything worked.
It only took me about 7 hours to work out, and I hardly got incredibly angry at all.
Hope it may help somebody!
I still have a similar issue.
I'm having a portrait only .folio 768x1024 (page by page) with horizontal only scrollable frames on multiple single pages.
The scrollable frames are full-with 768x1024 (portrait).
The content inside the scrollable frames have the size 1536 x 1024.
Swiping from page to page within the article (vertically) works well.
Swiping from current article to previous or next article doesn't work!
It sometimes works with two finger swipe gestures, tough.
The .folio is PDF but I've also tried PNG in article settings.
I've noticed, if the content inside the scrollable frame has same size (768x1024) or smaller as the parent frame (scrollable) it works.
This happens on iOS6 and iOS7.
Is it a bug?
Thanks for any help.