Okay, let's discuss this crawl view. A scroll view allows users to browse content, such as stacks in a document or a collection of images that's larger than the visible area. So you scroll you to give people access to large views, or to large numbers of views in a constrained space. Not that scrollview has no predefined appearance, except for the scroll bars appearing. As people swipe, Li crack, tap and pinch. A scroll view follows this gesture.

Revealing or zooming content in a way that feels natural scroll view itself has no appearance, but it does display transient scrolling indicators as people interact with it. A scroll view can also be configured to operate in Beijing, where scrolling reveals an entirely new page of content rather than moving around the current page. So the scroll view flashes transiting scroll indicators, also called scroll bars. When it first appears, and when users interact with the scroll view, as well. scroll bars are made visible as long as user is scrolling content. It responds to the speed and direction of gestures to reveal content in a way that feels natural.

For example, when users are slowly truck content in a scroll view, the content follows the touch. When users click content, on the other hand, the scroll view reveals content quickly and stops after some time. So this crawling needs to have inertia and friction. It also stops crawling when the user touches the screen, or when the end of the continent is reached. Also note that the iOS has this great little detail called a rubber band effect or elastic scrolling, which is my favorite thing when the end of scrollable areas and reached it lets you track the rubber a little bit The scroll view can also operate in a paging mode, in which each kragh a flick gesture reveals one up defined page of content. It's used often in the app walkthroughs together with the page control.

When you want to display content that's divided into pagers, screen polls or other chunks. You can use a pitch control to show users how many chunks are available and which one they're currently viewing. And when you do that, disable the scroll indicator that's on the same axis as the pitch control. Removing the scroll indicator as you understand focuses attention on the pitch control and gives people one unambiguous way to pitch through the content. If it makes sense in your app, lets users pinch or double tap to zoom into and out of a straw view. Here I am mentioning and then branching out of the image then I double top For the images, usually, the first double tap zooms in, and the next double tap zooms out.

Take a look at double tapping in Google Maps though. Each double tap just zooms for the up to the point, when there is nowhere to zoom into, and the zoom stops. I think it just starts taking you back. Just as with images, it should start as a mild when you hit the end, and zoom out you're starting low for example. When you enable zoom, you should also set the maximum and the minimum scale values that makes sense in the context of the users task. For example, letting users zoom in on text into one character feels This train is unlikely to make it easier for them to read the content.

So make sure the zoom levels make sense guys. Apple recommends to display just one scroll view at a time in general. guidelines claim that because people often make large swipe gestures when they scroll It can be difficult for them to avoid interacting with a neighboring scroll you on the same screen guidelines or command that if you decide to put two scroll views on one screen, consider allowing them to scroll in different directions so that one gesture is less likely to scroll both views. And yeah, the stocks app, for example does just that. As you see here, the top part is vertically scrollable. And the bottom part is horizontal scrollable in a paging mode, but take a look at Apple's own App Store app, which contradicts the guidelines of displaying only one scroll view at a time.

We have multiple scroll views here. And guess what people are completely fine using them. It does not hinder user experience. So you can do this as well. Lastly, don't place a scroll view inside of another strong view. Doing so creates an unpredictable interface that's difficult to control.