1 of 1 people found this helpful
set up two copies of a form view layout. Use the navigation part for buttons On one but put the buttons at the top of the body on the other. Size the body to be taller than fits on your display.
Now enter browse and and try vertically scrolling the window on both layouts.
I'm stuck in an airport waiting for a severely delayed flight. and thus can't test this, but I believe that the nav section will stay put when the rest of the layout scrolls.
Thanks for your response... When I put the nav buttons in the header (with no top nav part present) and then browsed a list, in list mode, (not form mode), the Nav buttons stay nicely on top, and the list info nicely scrolls below..
It looks like the only occasion where I would want to use the top nav part is when I'm printing something and want to suppress navigation buttons or other info I've placed in that part ...?
2 of 2 people found this helpful
You seem to miss my point. You get a new UI behavior when you do this in Form View. If you open a layout designed for form view and switch it to list view, it is true that the buttons stay in the header nicely, but scrolling scrolls you from record to record.
In form view, scrolling is limited to the current record, but with the new Nav part, you can keep content in place at the top of the screen while you scroll within the same single record and still have a found set of many records. This is new UI behavior not previously available to us.
One key feature of this is the ability to produce layouts that are more adaptive to the many different screen and monitor sizes now in use--especially when careful use is made of auto-size anchors so that the layout intelligently expands to use the extra space of larger monitors and reduces to a smaller size on smaller screens. Once that minimum is reached, the ability to scroll within the window while keeping navigation buttons visible on smaller screens is a very welcome feature and helps reduce the number of device specific layouts we might have to create.
There are other options, BTW, for keeping layout options from showing for printed/PDF'd/previewed layouts. We've had the "hide when printing option" for many years and versions.
1 of 1 people found this helpful
My apologies..I did miss your point !
Thank you so much for your very helpful explanation. I was stuck on the process of browsing "found" records in list view (only one line per record), from which a user selects the one to display in the larger (Form) view.
If the number of found records is relatively low, browsing them in form view while keeping the navigation info on top would work pretty well, particularly when using an iPad where swiping the screen can replace using "Next" or "Back" buttons.
Hope you are still not stuck at the airport !
Would be very useful for Form View exactly as you described but finally they screwed up by exclude Navigation Part from Zoom Level behaviour.
Zoom-Level for Navigation Part stays always 100%!
Yes. According to some answers in other threads, it's the expected behavior - but here, it's a no-go
It was over 5 hours (2 hours early for TSA followed by 3 plus hours delay) in a hot, crowded terminal in Las Vegas, but we did get home eventually.
Sent from my iPhone
Well, better late than never, I suppose....
Judging from the warm "welcome back" comments from many of your admirers, looks like I certainlylucked out getting your help on this topic!
I suppose the idea was to keep the nav buttons from getting too small for the user to use effectively when on a small screen. But keeping them at 100% would certainly appear to reduce their benefit, as you have implied.
..Oh, the pain of unexpected consequences !
Not only that: If your screen is too small, you cannot scroll to the side to see objects that doesn't fit in the resolution...
It should not be expected. It's retarded and very non-intuitive, and follow no common interface practice at all.