2.10 手势
人们通过在触摸屏上执行手势来与iOS设备进行交互。这些手势与内容有着密切的个人联系，增强了屏幕对象直接操作的意识。人们普遍希望在系统和应用程序中使用以下标准手势。
注：因编辑器无法插入动画，请参考原文动画。
Tap
单击（Tap）：激活控制或选择项目。
Drag
拖动（Drag）：从一侧到另一侧移动的元件或拖动在屏幕上的元素，例如调整元素顺序。
Flick
滚动（Flick）：快速滚动或翻转，如滚动相册。
Swipe
滑动（Swipe）：当用一个手指执行操作时，返回到前一个屏幕，在分屏视图控制器中显示隐藏的视图，在一个表视图行中显示删除按钮，或者在peek中显示操作。
Double tap
双击（Double tap）：拉近和中心内容或图像，或缩小如果已经放大。
Pinch
捏（Pinch）：向外捏的时候拉近，向内捏的时候缩小。
Touch and hold
触摸并按住（Touch and hold）：当在可编辑或可选择的文本中执行时，显示一个放大的光标位置的视图。当在某些视图中执行时，例如集合视图，进入允许重新排列项目的模式。
Shake
摇（Shake）：启动撤销或重做。
一般来说，使用标准手势。人们对标准手势很熟悉，不喜欢被迫学习不同的方法来做同样的事情。在游戏和其他沉浸式应用程序中，自定义手势可以成为体验中有趣的一部分。在其他应用程序中，最好使用标准手势，这样就不需要额外的努力来发现或记住它们。
不要阻碍系统的手势。除了标准的手势之外，一些附加的手势还会调用系统范围的动作，比如显示控制中心或通知中心。人们依靠这些手势在每个应用程序中工作。
避免使用标准手势来执行非标准操作。除非你的应用程序是为了活跃游戏中的游戏，重新定义标准手势的含义会导致混乱和复杂性。
提供快捷的手势来补充、替代基于接口的导航和动作。只要有可能，就提供一种简单的、可见的导航或执行动作的方式，即使这意味着额外的单击或双击。许多系统应用包括一个导航栏，它提供了一个清晰的、可切换的按钮回到前一个屏幕。但是，用户也可以从屏幕一侧滑动导航回来。在iPad上，人们可以通过按Home键，或者通过使用四根手指捏的手势退出到主屏幕。
使用多触点手势来增强一些应用程序的体验。虽然对每一个应用都有多个手指的动作并不适用，但它们可以丰富应用程序的体验，比如游戏和绘画应用。例如，游戏可能包括多个屏幕控制，诸如操纵杆和点火按钮可以同时操作。
2.11 加载
当内容加载时，一个空白或静态的屏幕会让你的应用看起来像是被冻结，从而导致混乱和沮丧，并有可能导致人们离开你的应用。
当加载发生时，请明确说明。至少，显示一个活动的转轮，表示正在发生的事情。更好的是，显示出显着的进度，以便用户可以衡量他们将要等待多久。
loading
教育或娱乐人们以掩盖加载时间。考虑一下游戏的提示，有趣的视频序列，或者有趣的占位符图形。
costom_Loading
自定义加载屏幕。虽然标准进度指标通常是可以的，但有时候他们有时会感觉不到上下文。考虑通过与应用程序或游戏风格相匹配的自定义动画和元素来设计更加身临其境的体验。
尽快显示内容。在看到他们期望的屏幕之前，不要让人等待内容加载。立即显示屏幕，并使用占位符文本、图形或动画来确定哪些内容是不可用的。在内容加载时替换这些占位符元素。只要有可能，在后台预加载即将到来的内容，例如在播放动画或用户正在浏览级别或菜单时。
有关其他指导，请参阅进度指示器。
2.12 模态（Modality）
Modality（译者注：临时视图）通过阻止人们完成任务或者关闭消息或视图来完成其他任务，从而创造了重点。行动表（Action sheets），警报（alerts）和活动视图（activity views）提供模态体验。
Alert
Modal View
最小化使用模式。一般来说，人们喜欢以非线性方式与应用程序进行交互。只有当某个任务必须完成或放弃以继续使用该应用程序或保存重要数据时，才考虑创建一个模态上下文引起关注。
提供一种明显而安全的方式来退出模态任务。确保人们在忽视模态的时候总是知道他们的行动结果。
让模态任务简单、简短、专注。不要在应用程序中创建应用程序。如果一个模态任务太复杂，人们就会失去当他们进入模态上下文时被暂停的任务。特别注意创建涉及层次结构的模态任务，因为用户可能会迷失方向，并忘记了如何回溯其步骤。如果模态任务必须包含子视图，请提供通过层次结构的单个路径和完成路径。避免在完成任务之外使用完成按钮。
如果合适，显示标识任务的标题。您还可以在视图的其他部分提供更完整的描述任务或提供指导的文本。
提供必要的和理想的可行动的信息的预备警报（alert）。Alert中断了体验，需要轻按关闭，所以重要的是让人觉得入侵是有必要的。要了解更多信息，请参阅警报。
尊重通知偏好。在“设置”中，用户可以指定他们希望如何从应用接收通知。遵守这些偏好设计，以免他们完全关闭应用的通知。
不要在弹出窗口上方显示模态视图。除了警报之外，除了警告之外，弹出窗口中什么也不应该出现。在极少数情况下，当你需要在弹出窗口中显示一个模态视图时，在显示模态视图之前关闭弹窗。
与您的应用程序协调模态视图外观。模式视图可以包括例如导航栏。在这种情况下，请使用与您应用中导航栏相同的外观。
选择适当的模态视图样式。您可以使用以下任何一种样式：
fullScreen_Modality
全屏。覆盖整个屏幕。用于可以在模态视图的上下文中完成的潜在复杂任务。
pageSheet_Modality
页面。部分涵盖了以横向为主的大型设备的底层内容。所有未覆盖的区域都变暗，以防止与它们的交互。在较小的设备上以纵向方向覆盖整个屏幕。用于可以在模态视图的上下文中完成的潜在复杂任务。
formSheet_Modality
表单。以屏幕为中心出现，但如果键盘可见，则可能会重新定位。所有未覆盖的区域都变暗，以防止与它们的交互。可能会在较小的设备上覆盖整个屏幕。用于收集信息。
curentContext_Modality
当前上下文。显示为与其父视图相同的大小。用于在拆分视图面板、弹出窗口或其他不是全屏的视图中显示模式内容。
选择适当的过渡样式以显示模态视图。使用与您的应用程序协调的过渡样式，并提高临时上下文转换的意识。默认的转换将模式视图从屏幕底部向上垂直滑动，一旦关闭就退回。翻转式转换似乎水平翻转视图以显示模态视图。视觉上，模态视图看起来像当前视图的背面。一旦驳回，它就会翻转。在您的应用程序中使用一致的模态转换样式。
有关模态视图开发人员的指导，请参阅UIViewController和UIPresentationController。
2.13 导航
直到它无法达到他们的期望，人们往往不知道应用的导航。你的工作就是在不引起注意的情况下，以一种支持你的应用的结构和目的的方式来实现导航。导航应该是自然和熟悉的，不应该主导界面或者把焦点从内容中拉出来。在iOS中，有三种主要的导航方式。
Hierarchical navigation
分层导航。在你到达目的地之前，每一个屏幕做出一个选择。要到达另一个目的地，您必须重新跟踪您的步骤或从头开始，并做出不同的选择。在设置和邮件使用了这种导航风格。
Flat navigation
平面导航。在多个内容类别之间切换。音乐和应用商店使用了这种导航方式。
NavigationExperienceDriven-Graphic
内容驱动或体验驱动导航。通过内容自由移动，或者内容本身定义导航。游戏、书籍和其他沉浸式应用程序通常使用了这种导航风格。
一些应用程序结合了多种导航样式。例如，使用平面导航的应用程序可以在每个类别中实现分层导航。
总是提供一条清晰的路径。人们应该知道你的应用在哪里，以及如何到达他们的下一个目的地。不管导航风格如何，通过内容的路径是合乎逻辑的、可预测的、易于遵循的。一般来说，给每个屏幕一个路径。如果需要在多个上下文中查看屏幕，可以考虑使用动作表单（action sheet）、警告（alert）、弹出窗口（popover）或模式视图（modal view）。要了解更多信息，请查看Action Sheets,Alerts,Popovers, andModality.。
设计一种信息结构，使其快速、容易地获得内容。组织你的信息结构，需要最少的点击次数，点击次数和屏幕。
使用触摸手势来创造流动性。通过最小的摩擦使你的界面更容易移动。例如，您可以让用户从屏幕的一侧滑动返回到前面的屏幕。
使用标准导航组件。只要有可能，使用标准的导航控件，如页面控件、标签栏、分段控件、表视图、集合视图和分屏视图。用户对这些控件已经很熟悉了，他们会直观地知道如何绕过你的应用。
使用导航条来遍历数据的层次结构。导航栏的标题可以显示层次结构中的当前位置，而back按钮可以很容易地返回到以前的位置。对于特定的指导，请参Navigation Bars。
使用标签栏来显示内容或功能的对等分类。不管当前的位置如何，一个标签栏可以让人们快速轻松地在不同的类别之间切换。对于特定的指导，请参Tab Bars。
当有多个相同类型的页面时，使用页控件。页控件清楚地显示可用页面的数量和当前活动的页数。天气应用程序使用页面控件显示位置特定的天气页面。对于特定的指导，请参Page Controls。
提示
分段控件和工具栏不支持导航。请使用分段控制将信息组织到不同的类别中。使用工具栏提供与当前上下文交互的控件。有关这些类型元素的附加信息，请参见Segmented Controls和Toolbars.。
2.14 评分和评论
评分和评论有助于人们在考虑是否尝试应用程序时作出明智的决定。积极的评价和评分意味着您的应用程序的更多下载，客户反馈可以让您深入了解现实世界的使用情况，从而帮助您评估未来的开发工作。
提供良好的整体体验是鼓励积极评价和评价的最佳方法，但在适当的时候要求反馈也是至关重要的。请求人们评价您的应用程序时，请牢记这些注意事项。
仅在用户展示与您的应用程序的互动后才能要求评级。例如，在完成游戏级别或生产力任务时提示用户。在首次启动或入场时不要求评级。允许用户拥有充足的时间形成意见。
不要中断用户。特别是当他们执行时间敏感或压力很大的任务时。查找逻辑停顿或停止点，评级请求最有意义。
不要打扰用户。重复的评级提示可能会刺激，甚至可能会对用户对您的应用程序的意见产生负面影响。在评级请求之间至少允许一周或两周，并在用户展示与您的应用程序进一步互动后再次提示。
2.14.1系统评级和审查提示
该系统为应用程序提供了一种一致的、非侵入式的方式来请求评级和评论。要使用这个功能，您只需标识应用程序用户体验中的位置，在这里请求反馈是有意义的。如果用户还没有给出反馈，而且最近还没有提出请求，系统会显示一个应用内提示，要求进行评分和可选的书面评论。用户可以通过一个点击来提供反馈或取消提示。(在设置中，用户也可以选择不接受他们安装的所有应用的评级提示。)在365天的时间内，该系统会自动将提示符的显示次数限制为每款应用的三次。
使用提供的系统提示。该系统的评级提示提供了一个熟悉的，高效率的经验，旨在使用户的影响微乎其微。
不要使用按钮或其他控件来请求反馈。由于系统限制了评级提示的频率发生，因此尝试响应控制请求反馈可能不会显示评级提示。
对于开发人员指南，请参阅SKStoreReviewController在StoreKit。
提示响应评论是与用户沟通，解决问题，并可能提高应用程序评级的好方法。有关最佳做法，请参阅Responding to Reviews on the App Store。
AppRating
2.15 请求许可
用户必须授予应用程序访问个人信息的权限，包括当前位置，日历，联系信息，提醒和照片。虽然人们欣赏使用可以访问这些信息的应用程序的便利性，但他们也期望能够控制他们的私人数据。例如，人们喜欢能够自动标记照片的物理位置或找到附近的朋友，但他们也希望禁用这些功能的选项。
仅在您的应用程序明确需要时才能请求个人数据。怀疑个人信息的请求是很自然的，特别是如果没有明显的需要。确保权限请求仅在人们使用明确需要个人数据的功能时发生。例如，一个应用程序可能只会在激活位置跟踪功能时请求访问当前位置。
如果请求不明显的话，解释为什么你的应用程序需要信息。您可以向系统提供的权限请求警报（alert）添加自定义文本。让文字更具体、更有礼貌，这样人们就不会感到有压力了。保持文本简短，并使用句子。不需要包含你的应用名称。该系统已经将你的应用程序识别为发出请求的应用程序。
只有在应用程序需要运行时才请求启动权限。如果用户的应用程序显然依赖于他们的个人信息来操作，那么用户不会被这个请求打扰。
permission
不要不必要地请求位置信息。在访问位置信息之前，请检查系统以查看是否启用了位置服务。有了这些知识，您可以将警报延迟到某个特性真正需要它的时候，或者可能完全避免警报。
要学习如何实现位置特性，请参阅位置和地图编程指南。
网友评论