我们总在期待 Next Big Thing，企盼下一次数字革命。喊了这么多年的物联网现在还没有明显起来的迹象，而 VR 也因为头戴设备的大型化和沉浸式场景的泛用性较差的原因，反倒是 AR 和 MR 依托智能手机、浴霸式镜头组和 APP 有一定起色，但是也没有到革命性改变的程度，只能算是一个小趋势。当然，人工智能/深度学习所带来的影响更加深远，但是短时间以内，它所带来的变化趋近于隐形。
而最近2年，各种双屏和柔性屏的发布，则可能是距离我们最近的硬件变革，可能和柔性屏/双屏设备有关。
也许现在说硬件交互设计到了类似 2007 年 iPhone 发布一样拐点有点夸张，但是对于现在几乎纯粹拼配置死水微澜一样的手机电脑市场而言，这种明显区别于以往的硬件设计，将会直接带来交互、设计和体验上的改变。
2019年是否算得上是双屏设备元年，现在下结论为时过早，但是去年三星 Galaxy Fold 和 Moto Razr 的发布，确实给广大硬件厂商好好打了一个样。
尽管Galaxy Fold 去年折戟沉沙了，但是高昂的沉没成本和大势所趋让三星肯定不能就这么算了， 回炉再造一番之后今年又带着船薪版本的 Galaxy Fold 2 杀将回来，顺带还兼顾女性市场整了一个对标 Moto Razr 的化妆盒手机 Galaxy Z flip。
图片来自 TheVerge
当然，华为的 Mate Xs 也是相当优秀的产品，这款明显对标三星 Galaxy Fold 2 的产品，并没有将柔性屏制作成为向内折叠，而是完全翻过来，将它作为外屏来进行设计，反向折叠，展开的时候，屏幕自然延展。
图片来自 TheVerge
不过思路最为清奇的并非是华为，而是 TCL。就在这几天，TCL 带来了两款全新的原型机，一款手机带有两个折叠轴，相当于是将传统手机屏幕延展到以往的3倍，彻底折叠开相当于是一个 10英寸的平板电脑（回过头来想，就像是将一个平板电脑反向折叠到手机的大小，但是重量不变……）。
图片来自 TheVerge
另外一款原型机则选择了抽拉式的设计，机身可以如同抽屉一样拉开，柔软的屏幕会被拉出，延展开来差不多和 iPad Mini 一个大小了。
图片来自 TheVerge
图片来自Engadget
除了这几款之外，在今年年初的 CES 消费电子展上，联想、戴尔、华硕，这些目前世界上最大的消费电子制造商，纷纷带来了各自的折叠屏和双屏设备。
联想带来的 ThinkPad X1 Fold，是一个价格昂贵的柔性折叠屏平板电脑，它额外附带了一个蓝牙键盘。
图片来自 TheVerge
考虑到联想在此之前已经发布过带有LEC+墨水屏的双屏设备 Yoga Book 2，可以说联想是已经具备了制造两种不同类型屏幕设备的能力。
作为对手的戴尔，带来了分别对标联想这两个系列的对应产品：Concept Ori 和 Concept Duet。
Concept Ori 采用的是两块传统硬屏，你既可以让一款屏幕作为屏幕，另一块作为虚拟输入键盘或者手绘板，也可以使用配备的蓝牙键盘，吸附在底下的屏幕上来进行输入，而且当键盘移动到靠近转轴的地方，还能让底下露出的半块屏幕作为触控板来使用：
图片来自 TheVerge
Concept Duet 在概念上则和 联想的 ThinkPad X1 Fold 类似，一块柔性可折叠的屏幕，便于收纳，一体连接。
图片来自 TheVerge
看了这么多硬件，是不是觉得信息量有点大？不过简单来说，所有的这些产品，都在说一件事情：屏幕要延展开，这是一个正在发生的趋势。
同时，我们还注意到一个很明显的特征，就是所有的这些柔性屏设备都非常的……骚，且贵。动辄两三千美元的起步价，如果可靠坚挺也就算了，不仅转轴易损，且屏幕也存在易损的问题。根据 ifanr 的上手评测，即使是在优化了转轴和屏幕折叠角度之后，三星所发布的 Galaxy Z Flip 的屏幕中段依然有着不可忽视的折痕，这一问题可能会是绝大多数折叠柔性屏设备的通病。
图片来自爱范儿
与之相反，采用硬质双屏设计的硬件设备，从生产成本、工艺成熟度、价格上，都更加有优势。
值得注意的是，柔性折叠屏和硬质双屏设备，在基本的使用体验和逻辑上是一致的，除了极少数特殊的设备之外（比如 TCL的双折叠式的概念机），多数情况下，两者是差不多的。
只不过存在一个问题，双屏设备的交互和体验，需要有对应操作系统支持，因为从单屏到双屏，其实交互逻辑已经发生了巨大的改变。
一直在创新且「稳健」地更新软硬件的苹果公司，应该不会在市场未曾成熟的情况下选择发布硬件，这意味着你不会很快看到双屏 iOS 硬件，而面向着大量 OEM 厂商的 Android 和 Windows 则截然不同。着两年厂商已经身体力行证明了一件事情：只要操作系统和设计跟上，硬件马上量产不是问题。
最近泄漏的 Android 11 的新特性已经出现了可折叠屏幕的影子，但是具体情况恐怕要到因为疫情跳票的 Google I/O 大会上会揭晓答案。但是另一边，贼心不死的微软，已经开始布局面向可双屏设备的新一代操作系统 Windows 10X了。
图片来自 TheVerge
去年微软发布的两款双屏设备 Surface Duo 和 Surface Neo 并不都是采用尚未发布的 Windows 10X 操作系统，但是两者都沿用了几乎相同的交互逻辑，较小的 Neo 采用的是 Android 操作系统。这两款硬件和系统交互设计，将会在未来一段时间以内，成为双屏硬件的软件交互的重要参考和主要标杆，联想和戴尔这波 OEM 厂商，无疑是参考着微软的风向标来搞硬件产品的。
图片来自 TheVerge
传统而臃肿的「开始」菜单栏在 Windows 10X 当中，被精简为我们更熟悉的模式，新的 Windows 10X 在原有的 Windows 10 的基础上，应该有对移动端（比如 ARM 架构的CPU）和小屏幕有更好的支持。
但是，更有价值的，是微软为双屏设备所制定的交互设计规范。
下面是基于微软官方文档，精简编译后的规范：
双屏交互概述
双屏设备可以基于不同的工业设计，有多种硬件样式。微软发布的 Surface Neo 和 Surface Duo 可以作为典型的双屏设备作为参考。双屏本身可以借由铰链、转轴来连接，也可以基于柔性屏来实现。
所有的双屏设备都具备有折叠、旋转、翻转的功能，两块屏幕都可以用来作为显示，也可以一个做屏幕一个承载虚拟键盘，当然也可以借由外设，构建、组合成为新的模式。所以，为这样的硬件设计的时候，需要考虑到各种不同的情况，并且适配硬件，帮助用户实现更多的目标。
:no_upscale()/cdn.vox-cdn.com/uploads/chorus_asset/file/19247637/akrales_190930_3649_0139.jpg)
图片来自 TheVerge
当用户打开应用的时候，它的主要界面窗口应该最大化，占据一块屏幕的全宽和全高。这样用户可以一次打开多个不同的应用，显示在双屏上。
图片来自 TheVerge
当然，你的APP 也可以完整铺满两个屏幕，这个界面布局被称为「跨屏布局」。在默认情况下，它应该像在大屏幕上一样，一个窗口跨屏幕显示。但是你可以修改这种模式，让它可以铺满两个屏幕的同时，还可以兼顾到中间有转轴和铰链的硬件。对于这个问题，我们随后有详细的讨论。
响应式布局
比起传统的响应式布局，对于双屏硬件，我们要讨论的「响应」模式要复杂得多。就像下面这张图中所说的，要为这样多样、复杂的情况进行设计：
我们默认用户在多数时候，是处于双屏展开的状态，当用户打开 APP 的时候，它的主要界面窗口，将会最大化占据一个屏幕，这个时候另一个屏幕处于空置状态，用户可以在这个屏幕上打开另外的应用，并且用户可以通过托拽窗口的方式，来重新整理窗口和APP的排布模式。
同时，单个应用程序也应该可以进行跨屏布局，既可以让单个应用分别在两块屏幕上各呈现一个窗口，也可以作为单个窗口完整铺满两块屏幕。不论是充分利用接缝的存在，还是说尽可能地利用全部屏幕区域来聚焦单个内容，应用程序应该都可以做到。当然，这些情况我们随后会单独说到。
首先，作为一个已有的应用程序，在双屏设备上应该能够继承原有的功能，并且尽可能地兼容双屏的体验。在开始讨论如何为双屏场景进行设计应用之前，我们先应该对双屏交互进行介绍。
双屏的响应式布局
首先，无论屏幕尺寸如何，方向如何，应用程序应该都可以保持良好的外观，善用 UI 平台的现有的布局技术，通过合理地缩放来自适应，填满屏幕。如果你的屏幕元素依赖屏幕长宽比，那么应该善用平台给的 API 来进行灵活的优化。
考虑到你的应用将会在很多不同尺寸、不同长宽比、不同类型的设备上运行，所以你的应用程序应该足以应对各种不同的情况。请记住，你的设计将会遭遇和以往截然不同的屏幕尺寸和长宽比，比如纵向（全景视图）、横向（较宽的全景视图）、纵向双屏分别显示等不同情况。
考虑所有的屏幕方向
用户在很多平台上有习惯的、常见的屏幕方向，比如在 Android 和 iOS 上，通常应用是竖屏显示的，在 Windows 上，多数情况下是横向全屏显示的。而在双屏设备上，这种情况会发生改变。
比如你的应用原本是为竖屏设计的，但是需要经常输入内容，那么你要考虑到双屏设备上，你的应用可能是会被横屏显示，用户会像用笔记本电脑那样来使用应用，也就是说两块屏幕都横向显示，靠下平摊在桌面的屏幕会显示虚拟键盘或者手写区域，作为输入窗口，而显示窗口也是横向的。
双屏为多任务提供更好的显示环境，你不会知道用户会在什么样的场合，以什么样的姿势来握持设备，但是考虑潜在的使用姿态，可以让你更好得对应用进行设计和优化。
根据我们的研究，如果你的应用是注重输入的应用，那么用户在平面上打字和输入将会是最舒服也最常见的姿势。那么在这种情况下，你应该针对横屏显示进行针对性的优化。
支持多种输入模式
对于新的双屏设备，通常都支持多种输入模式，包括打字输入，屏幕触摸和手写笔这样的截至。这意味着用户可以灵活地根据需求，选择不同的姿势和输入模式，并且快速切换，以适应不同的需求。
换句话来说，就是你在设计的时候，需要支持所有的输入方式，以便用户可以自由选择交互模式。
托拽交互
你的应用应该支持屏幕托拽，这不仅是为了兼容双屏设备，而是对于绝大多数的设备的使用情况而进行兼容，确保用户体验的一致和灵活。只不过相比于在屏幕单屏上进行托拽移动，在双屏上托拽移动，将会带来更多的可能性，并且这样也将会在双屏使用场景之下，最为重要的交互模式之一。
为了确保托拽操作的自然，你需要确保诸如文本、图像、视频等常见的交互对象和元素，可以在任何地方进行剪切、复制、粘贴，并且对于共享和放松之类的操作也启用托拽操作，这将最大化地利用双屏的优势。
应用的多屏呈现
用户会希望在两块屏幕上并排显示同一应用中的不同内容，因此你的你用应该支持多实例呈现和运行。
多媒体内容画中画体验
如果你的应用是一个多媒体应用，那么应该支持画中画模式，用户可以边看视频边执行别的操作。
上面提及的很多功能属于基础应用要求，并不是专门针对双屏设备而做，但是如果你的应用支持上面的功能，那么在双屏上将会明显拥有更好的用户体验。接下来，我们着重聊一下在双屏设备上进行设计的问题。
在双屏设备上，你的应用应当支持在单个屏幕上运行，也可以在双屏上运行，当一个应用在两个屏幕上显示的时候，我们称之为「跨屏」，而跨屏显示这个问题对于双屏设备而言，是至关重要的，如何显示将会带来巨大的影响。这种独特交互模式可能会解锁前所未有的使用方法。比如，有转轴和接缝的双屏设备，因为屏幕的特征而非常适合分隔并行式的生产力解决方案。
跨屏是用户的选择
用户有选择如何使用应用的方式的权力，包括何时跨屏显示。某些应用可能在单屏或者跨屏显示的时候，看起来不够好看，但是如何使用的权力，应该交给用户去选择。
尽管本文会针对如何处理多屏布局提供几种不同的方案和想法，但是请选择适合你的用户和应用的呈现方式。
考虑用户意图和设备方向
当你的两个屏幕都被利用起来的时候（横向双屏，纵向双屏），了解用户的意图至关重要。尽管还有更多的调研需要做，但是结合我们目前已有的观察，可以得出如下的趋势：
在为双屏设备设计应用的时候，有四种常见的布局方案是你需要考虑的。通常这取决于应用是单屏还是跨屏，是默认视图还是全屏视图：
1、单屏默认模式
2、跨屏默认模式
3、单屏全屏模式
4、跨屏全屏模式
当单个应用以单个窗口运行，并且跨越两个屏幕的时候，跨屏布局就出现了。如果你原有的应用从未针对双屏设备进行优化的话，那么系统会提示你「应用将会扩展并占据所有屏幕」，并且这个时候，应用界面会自行调整大小，适应新的尺寸。
这种情况下，界面中间的接缝会显得非常明显。这是双屏设备先天的副产物。要如何优雅地处理接缝？这就是下面这节内容将会探讨的问题，我们将会提供一些常见的处理方案yi。
是否总是要适应接缝？
如果你的应用不作任何优化就直接在双屏设备上投放使用，接缝并不总会给用户体验带来影响。比如地图类应用，用户可以随意移动地图内容，接缝带来的割裂并不会对使用体验造成实质性的影响。在后面「扩展画布」这一节，将会对这个问题进行深入讨论。
但是对于另外一部分应用，接缝带来的问题就非常严重了。比如在一个表格类应用当中，如果不作修改和调整，有的内容会直接被接缝给割裂开，你必须进行滚动才能正常查看。而对于某些相对更加固定无法移动的元素而言，接缝带来的体验是破坏性的。而这个时候，我们需要使用一些技术方案来处理这个问题。
规避接缝
将元素移到一边
由于两块屏幕之间有明显的接缝，因此当用户在使用应用的时候，某些 UI 元素可能会正好被穿过接缝，逻辑上这不会影响功能，但是如果将这些 UI 元素移动到屏幕的一边来显示，会提供更好的体验。最好避免在接缝处显示文本内容，这会影响可读性。
应用程序对话框应该移到屏幕的一边，尤其是需要点击按钮操作的时候。
底部菜单应该移动到屏幕一侧，而不是延伸到两个屏幕上。
用户调用上下文菜单的时候，应该将接缝视作为屏幕边界处理，尤其是在靠近屏幕边缘的地方触发菜单的时候。
应用内的下拉菜单或者可扩展容器如果可能会跨越接缝的话，应该改变扩展方向。
当整个应用界面扩展开来的时候，应该整个移动到屏幕的上侧，而不是在靠近中心的位置横跨接缝。
贴合接缝
使用偶数列并和接缝对齐
当界面中使用网格布局的时候，垂直或者水平方向尽量使用偶数行或者偶数列，这样可以让接缝和界面间隙正好重合，用户可以更加舒适地查看信息。
在网格中使用偶数列，尤其是对于容器、表单，并且考虑到接缝来控制间距。
除此之外，还有许多应用会考虑充分利用另外一个屏幕来显示弹出菜单或者下级页面的内容。这种使用逻辑确实会让应用更加易用，并且在视觉上会更加干净清爽。但是请记住，如果弹出的界面并不是全屏的，可能会暗示它是可折叠和可关闭的，因此，你需要根据实际的设计需求，来灵活的处理呈现样式。全覆盖另外一屏的弹出界面，更加适合小尺寸屏幕。
重新排列 UI 元素
移动到接缝的任一侧
还有一种用来优化响应式布局的方法是，当屏幕方向或者大小发生变化的时候，重新排列你的内容。这种方式让你可以在两个屏幕上随意扩展你的内容，你可以通过分组来重新排列，以更有目的的方式来适配屏幕和内容。
遮罩和分割
对于一些无法重新排列的元素，比如全屏图片和视频，这个时候只能使用遮罩和分割的方式来处理。
遮罩的思路是，将接缝视作为一个遮罩元素，而图片被它给遮挡了一部分，根据格式塔原理，我们的大脑会自动补足缺少的部分，遮罩遮罩处理方式适合处理多媒体（视频，图片等）这样的画布类型的场景，在这些场景下，保持图像的连续性比显示内容的完整性更加重要。
分割的思路是将内容均匀切割为两个部分，完整呈现，这对于包含有多个控件和元素的普通界面而言，是更加合理的处理方式，包括可能会出现在屏幕中间的按钮。
根据类型的不同，这两种处理方式各有优势，我们将继续跟进不同的用户行为特征，来寻求更优的解决方案。
文章来源：优设
旅程映射创建了一个完整的体验视图，正是这一过程将不同的数据点聚集在一起并进行可视化处理，以了解产品需求，从而可以吸引各个群体中不感兴趣的利益相关者，并促进协作性对话和变革。可通过揭示一系列交互过程中沮丧和愉悦的时刻来帮助了解客户体验，揭示了满足客户痛点，减轻分散性的机会，并最终通过暴露新机会提供附加价值而最终使产品脱颖而出。
如何使用旅程映射来了解与公司互动过程中的客户行为，思维方式和情感动机。旅程映射在理解和优化客户体验方面的实际应用，以及收集研究和从该研究中得出真实叙述的方法。
了解旅程图何时是有用的设计工具，以及如何向拥有预算批准的客户或团队成员阐明该工具的优点。如何使用成品传达见解，与跨部门团队成员互动以及如何通过发现激发变化。
旅程映射分为4条泳道：阶段，动作，思想，心态/情绪。省略大多数流程细节，反映了用户的思想，思考和情感。
旅程映射的价值：
客户旅程图的目标
将服务蓝图视为客户旅程图的第二部分。它们是旅程地图的扩展，但它们不是专注于用户（并从用户的角度出发），而是专注于业务（并以其视角）。他们可以在特定客户旅程中的各个接触点上可视化不同服务组件（例如人员或流程）之间的关系。客户旅程图之后，在进行组织或流程更改之前，内部查明漏斗或断点时使用服务蓝图。
客户旅程地图的目的是更好地了解最终用户的旅程。这段旅程包括他们的思想和情感。相反，服务蓝图反映了组织的观点，因此包括前期行动，后台行动和支持流程。客户旅程地图的主要重点是了解有关最终用户的更多信息，而服务蓝图的重点是记录组织如何创建这种体验。
制定有效旅程图的五个步骤
界限
对于要创建多少个旅程图没有严格的规定。旅程映射作为一个过程是有益的，因为它在团队成员之间建立了共同的愿景。通常，客户旅程图越集中，越好。在一种情况下，专注于一个角色的旅程图讲述了一个清晰的故事。
宽度与深度
确定旅程映射的范围广度，过程和范围的不一致和含糊不清会导致失败。
要素的平衡和重点
要素：角色，情境，动作，心态，情绪，接触点，渠道，发现。渗透各个要素及以接触点为重点从而发现机会点。
使用环境
明确使用环境，在如何的环境下使用，物理环境以及数字环境等。
接触点和渠道
接触点代表客户与组织之间的特定交互。包括正在使用的设备，用于交互的通道及已完成的特定任务。客户旅程由一系列接触点组成，每个接触点定义了特定交互的细节。地图应使接触点（地图中的参与者实际与公司互动的时间）和渠道（通信或服务提供方法，例如网站或实体商店）与用户目标和行动对齐。这些元素值得特别强调，因为它们经常是发现品牌不一致和脱节的体验的地方。
语境查询
观察用户执行任务时，您可以提出问题，从而可以澄清您的观察并引发开放式对话。
任务分析
任务分析最常见的产出物就是那些对用户为达成目标所采取步骤/行为的描绘。当我们把所有这些步骤都解析清楚了，就很容易发现用户在哪些步骤中付出了额外的努力，哪些步骤是能够直接去除以缩短操作流程的。
日记研究
由于客户旅程会随着时间的流逝并通过许多不同的渠道发生，因此日记研究是了解用户随时间推移的想法，感觉和动作的一种特别有用的方法。日记研究是一项长期研究：要求用户记录与特定目标相关的每项操作，以及他们在互动过程中的感受很多天，几周或几个月。由于参与者的行为，感受和想法尽可能接近实时地捕获，因此消除了访谈所依赖的（容易出错的）记忆。还在旅程的所有阶段（而不是一个阶段）从参与者那里获取数据。日记研究的建立成本低廉，可以在进行其他类型的研究时在后台运行。
定量支持
旅程地图应该产生真实的叙述，而不是童话故事。从收集任何现有研究开始，需要其他基于旅程的研究来填补现有研究无法涵盖的空白。这是一个定性研究过程。虽然定量数据可以帮助支持或验证（或帮助说服可能将定性数据视为「模糊」的利益相关者），但仅凭定量数据无法建立故事。
旅程映射过程的整个重点是发现用户体验中的差距（这在全渠道旅程中尤为常见），然后采取行动来优化体验。洞察力和所有权是经常被忽略的关键要素。从旅程映射中得出的任何见解都应明确列出。可以为旅程地图的不同部分分配所有权，以便清楚地知道谁负责客户旅程的哪个方面。没有所有权，没有人有责任或权力去改变任何东西。
文章来源：优设 作者：Design Thinker
在这之前我得先提及一本书──《简约至上：交互式设计四策略》。这本书基本算得上是交互设计的入门必读书籍了，非常适合身处项目环节中上游的人员阅读与学习。
作者 Giles Colborne 在书中提出了四个令交互设计成果最大化的简易策略：合理删除、分层组织、适时隐藏和巧妙转移。这四个策略几乎成为我设计与优化每一个页面时的自我指导方针。
我参阅了大量的应用，想总结出它们是如何运用导航栏来给产品赋能的。竟然很巧地发现，再花式的导航栏设计也难逃「四策略」手法。
首先，导航栏作为一个独立控件，它本身就已经是「分层组织」策略的一种表现形式。接下来我们来看看，优秀的产品设计是如何运用另外三种策略来设计好导航栏的。
导航栏不能轻易删除，但凡事没有绝对。什么时候我们可以合理地删除导航栏呢？
Nike Run Club（下文简称NRC）是耐克官方出品的一款跑步记录 APP。既然做产品要站在用户角度出发，那我们就来复原一下主要功能的用户使用场景。
当你的老板要求你一天出 150 个界面设计的时候，你怕了，准备跑路，同时又不想浪费一天中任何一次记录运动的机会。于是你打开 NRC，你的目的很明确：认真地跑路，并记录运动。
点击「开始」按钮，当你一旦开始跑步，手机基本就不再使用了，直到跑步结束。
△ NRC在运动状态下的界面删除了导航栏
在用户记录跑步这样一个单一事件中，NRC 知道你会专注运动，很少存在关注其他功能、浏览其他页面的可能性。于是 NRC 可以很干脆地删掉导航栏，而返回按钮用了界面中的「结束」按钮代替。
滴滴出行在呼叫快车时也做了删除导航栏的处理。用户一旦发单，开始呼叫司机时，呼叫页面内的所有操作都只聚集在界面下方的一个视觉区域内。
△ 滴滴出行在呼叫过程中删除了导航栏
上面两个删除导航栏的示例有什么共通点呢？
第一，用户在当前页面的事件状态明确，不需要导航标题提醒用户当前在什么位置，用户也极少可能在当前页面发生其他事件操作，于是完全可以去除导航标题与内容控件。
第二，虽然删除了返回按钮，但都采用了很典型的「费茨定律」，就算用户误操作，也能便捷地撤销正在发生的事件。反而这比循规蹈矩地运用导航栏来承载返回按钮合理了许多。
△ 费茨定律简易图解
既然导航栏内所有的规范元素都有可取代方案，为什么不删除它呢？正如 Giles Colborne 在书中告诉我们的：大胆地删除，但也不要极端到盲目删除。
隐藏和删除看起来十分相似，但其实不然。我们如何区分这两个技巧呢？
隐藏最常见的情况是，当导航栏的出现会成为打扰用户沉浸体验的障碍时，我们会选择隐藏，例如看视频、浏览图片等显示全屏媒体的场景，有导航栏反而会分散用户的注意力。
△ 显示全屏媒体时需要隐藏导航栏
不知道你有没有发现到一个细节，在大多数情况下，需要沉浸体验的页面不但会隐藏导航栏，同时也会隐藏状态栏，导航栏中载有当前页面的标题、导航按钮和内容控件；状态栏中会载有时间、Wi-Fi 等系统设备信息。
iOS 在人机交互指南中提醒我们，显示全屏媒体时，请考虑暂时隐藏状态栏，但请避免永久隐藏。如果没有状态栏，当用户需要查看时间或其他设备信息时必须离开应用。设计师应该让用户可以使用简单的手势重新显示隐藏的状态栏。
△ 用户可以方便地查看时间或其他设备信息
另一种情况是当前页面非常注重一屏内容展现时，我们会隐藏导航栏。
京东在用户搜索了商品之后，头部有三个信息栏，非常冗长。分别是：
△ 京东搜索商品后屏幕头部的信息栏
用户在搜索了商品之后，向上滑动页面，京东会隐藏导航栏和全局筛选栏。
一是因为用户搜索关键词后，滑动页面大概率表示已经开始在挑选商品，这时候可以大胆地猜测用户行为，认为搜索与排序的重要级下降了，搜索结果垂直内容筛选的重要级上升了，便可以只保留下重要的操作。
二是可以让内容区域高度增加，隐藏顶部两个栏目区域可以大致增加一个商品位的提前露出，增大了商品触达用户的可能性。这不就是 UI 设计为商业目标赋能的一个案例吗？
△ 隐藏导航栏，增加了屏幕利用率
基于导航栏层级始终高于页面内容的特性，随着用户划出第一屏，许多 APP 做了重要内容或重要控件转移到导航栏的设计。
豆瓣在影评讨论区，用户上滑页面时，会将当前影片的信息转移到导航栏。其实这种转移很常见，许多内容社区 APP 都有这样的交互设计，比如浏览的公众号文章，再回到顶部试试。方便用户时刻知道自己当前所浏览的内容是关于哪一个主题的。这一类转移是单纯站在用户体验角度的考量。
△ 豆瓣在屏幕滚动后转移影片信息到导航栏
但如果你仔细观察，有一类转移却是综合了用户体验与产品目标的共同抉择。如果你再稍微了解一点该产品背后的故事，甚至可以让你洞悉到，为了巩固产品的调性和目标，PM 和 UI 们在页面设计时做了多少细枝末节的引导。
知乎在用户浏览当前问题时向上滑动页面，也会像豆瓣一样，将当前问题标题转移到导航栏上，但与此同时会将「写回答」的操作也转移到导航栏。标题转移是出于用户体验，和大多数内容社区的做法大同小异；而「写回答」的按钮转移，正符合知乎想要打造一个内容交流社区的产品调性，他们希望刺激用户进行问答互动，多输出 UGC 内容，希望用「写回答」的按钮转移进一步激发用户创作内容的可能性。
△ 知乎转移「写回答」让用户更方便地进行问答互动
京东在店铺首页上滑页面时，会将「关注」按钮转移到导航栏，方便用户在浏览的过程中可以随时收藏店铺，增加了用户对品牌店铺的关注度和复购的可能性。京东靠自营模式发家，近几年来开始慢慢重视 B2C 市场，在这个小小的关注按钮上，是不是可以算略显端倪呢？虽然我不能非常肯定，可能提高用户收藏操作只是为了辅助京东更好地进行营销权重划分，不过「关注」按钮的转移，确实能为 B2C 业务的渗透提供一份助力。
△ 京东转移「关注」让用户更方便地收藏店铺
所以我这里说到的「转移」的目的，其实和 Giles Colborne 在书中讲到的并不十分一致，Giles Colborne 是希望设计师将当前页面低频、冗杂的操作转移到另一个页面中去，而我提到的「转移」反而是产品越注重什么功能，越可以利用导航栏层级的先天优势来实现转移。
合理删除、分层组织、适时隐藏和巧妙转移已经是我做设计和分析界面常用的一个手法，它并不一定是万能的，但是它多多少少可以辅助我们做出更合理的设计。
这篇文章想要告诉大家的是，在平台规范里的导航栏是死板又相对静态的，但在四个策略的辅助下，结合用户的操作手势，也可以将它变得十分灵活，帮助页面实现更好的用户体验。不要被规范限制的太死，转换设计师的角色变成用户，你可以研究出更多好玩的操作。随便打开一个应用，去研究研究，你可能会乐在其中的。
文章来源：优设 作者：UCD耍家
知名的免费图标网站 Iconfinder 要和大家一起对抗新冠病毒，和图标设计师联手推出一系列「防疫免费图标集」（Coronavirus awareness icons），超过 200 个与公共卫生、病毒传播相关图标，这些图案包括常见的 PNG 和 SVG 格式，可以将它们加入标志、海报、传单或类似的内容使用。
如果你想要制作广告牌，提醒在这个区域要洗手或戴口罩，这里有免费图标可让信息更容易被阅读。
依照 Iconfinder 网站说明，这些图标可用于洗手说明、卫生建议或是其他预防病毒传染散播的提醒信息，所有图标采用 Creative Commons BY-SA 3.0 授权释出，使用时需要标示出处，并以相同方式分享。
网站链接：https://www.iconfinder.com/p/coronavirus-awareness-icons
值得一试的三个理由：
前往 Iconfider 的「Coronavirus awareness icons」网站，就能看到这套专为对抗新冠病毒提供的免费图标集，点选 Download all icons 下载打包好的完整图标。
在网站中展示一些收录在这套图标集的防疫相关图案，每套图案都有不同风格，例如以单纯线条为主的设计，或是采用平面化设计的彩色图标，可以依照自己的需求选择。当然你也可以按下右上角的按钮前往 Iconfinder 找到这套图标的完整版本。
下载后就能取得完整的图标集，依照不同名称分类，有些是 SVG 格式，有些则包括 SVG 和不同大小的 PNG 文件，其中有个 iconfider_freebies.zip 在解压缩后还能取得一些和防疫相关的图标。
值得一试的三个理由：
文章来源：优设 作者：Pseric
Persona，在国内通常被称为「用户画像」，其概念最初由 Alan Cooper 在 1999 年提出。由于用户画像具备帮助人们在设计过程中聚焦于目标用户的需求，促进团队中不同利益相关者的沟通等作用，而逐渐成为被广泛使用的经典设计工具。也正是由于其经典地位，我们往往对用户画像在各类设计场景中的出现习以为常，却很少去对这一工具进行反思。本文将基于用户画像的研究现状，对其存在的问题与局限进行综述和归纳。
Matthews 等学者为了探究设计师以及经验丰富的用户体验专家对用户画像的实际看法，从北美一家科技公司招募了 14 名设计师作为参与者。值得一提的是，这家公司拥有庞大且富有影响力的设计团队，另外这 14 名参与者中，在设计领域有 10 年以上工作经验的人数过半。通过访谈的方式，Matthews 发现，大多数参与者在实际工作中都不会使用到用户画像，并分析了为何不用的 4 类原因。我将 Matthews 等原文中的 4 类原因归纳为以下 3 条。（下文中出现的 D1、M3、B1 等序号是参与者的编号）
1. 太过抽象
D1：如果你只向他们（指开发团队）展示用户画像，他们是不会相信的。只有当他们看到用户画像背后有足够的数据支撑，他们才可能相信。
其实，不止是设计师有这样的看法，Basecamp（原37signals）的创始人 Jason Fried 在他的一篇博文里曾这样说：它们（指用户画像）是模拟的、抽象的、虚构的，我不认为你能为一个压根不存在的人创造出优秀的产品。
2. 缺少人情味
M3：我认为，有很多细节和微妙之处是无法通过对用户画像的描述而传达的，我也不认为有人能像用户画像那样思考或行事。坦白地说，我一直对用户画像以及它的用途充满怀疑，我觉得它更像一个沟通工具。
缺少人情味的另一点在于：用户画像太过理想化。
B1：他们（指用户画像）描述了最为完美的用户（对所设计的系统有着超乎寻常的热情），以及最为匹配的情节。而真实的用户并不像这样，因此，用户画像并没有很多作用。
3. 属性无用，甚至有误导作用
我们知道，一个用户画像在被创建的过程中，往往会被赋予若干个属性，常见的基本属性包括：年龄、职业、居住地等等。在访谈中，有些参与者表示，那些被赋予在用户画像身上的属性没什么用处。
A1：用户画像的数据完全没有用。如果它是一个真实的人，我可能还会关注，但它本身不是一个真实的人，是那些添加在它身上的装饰让其看起来像真实的人，我觉得这是无用的。
还有一些参与者认为，用户画像身上的属性和细节太过分散，导致偏离了本应关注的重点。
L1：在创建用户画像的过程中，我常常发现，那些原本次要的方面反而变得更加突出了。你会发现，那些与关键维度并非真正相关的细节，像技能、工作职责、对软件和工具的熟悉程度，这些细节很容易提出，因为它们也同样容易去沟通和理解。然而，随之而来的代价是，把更为重要的细节给丢掉了。
1. 代表多少
Chapman 等学者指出，任何一个用户画像都仅仅只能代表潜在用户群体中的某一小部分。那创建多个用户画像是否可行呢？可行是可行，但这又引出了一个新的问题：当用户画像的数量增多时，它的可记忆性是降低的，相应也降低了它在设计中起到的作用。多个用户画像往往存在着信息冗余的问题，过多的用户画像还会大大增加设计决策的成本。对于通过大数据自动生成的用户画像，数量过多这一问题尤为明显：有时会产出成千上百个用户画像。
2. 属性越多，涵盖面越窄
既然用户画像所代表的是真实用户，那么，它涵盖的真实用户数量能否通过某种方法预估出来呢？上文中我们提到的属性（如年龄、职业、居住地等），为用户数量的预估提供了可能。基于以上问题，Chapman 等展开了定量分析的研究。他们一共选取了 8 个数据库，其中 6 个是通过市场调研得出的真实用户细分与特征数据库，另外 2 个则通过多元数据模拟出来。然后，逐一地去增加用户画像的属性数量，并依次与数据库进行匹配。实验的结果如下图所示。不难发现：当用户画像被赋予的属性增加时，它涵盖的真实用户比例是降低的；而属性数量增加至 9 个以上后，各个数据库的匹配率都很低。对此，Chapman 等的建议是在创建用户画像时，最好能对其涵盖的用户数量进行大致的评估，而不是简单的假设。
△ 属性越多，涵盖面越窄
1. 偏低的投入产出比
前文中有提到，Matthews 等通过访谈去了解设计师对用户画像的看法，但这项研究还不足以观察到设计师是如何将用户画像运用到实际工作中的。基于这块研究的缺失，学者 Friess 另辟蹊径，从民族学的角度出发进行了探索。她采用的方法是：选取了一家位于美国的设计公司，对它其中一个团队的设计决策过程进行全程地观察与录音。该设计团队由 4 名核心成员组成，在设计决策开始前，其中 2 名团队成员已经花费了数周时间，通过调研创建了 8 个用户画像，并输出了长达 20 页的用户画像文档，供团队其他成员阅读。Friess 对收集到的录音片段进行话语分析后发现：在整个设计决策过程的话轮中，用户画像被提及的比例仅为 3% 左右。而且，在这为数不多的 3% 中，85.3% 的比例又是由那 2 名创建用户画像的成员提出。长达数周时间所创建的用户画像，换来设计决策过程中约为 3% 的提及率，这个投入产出比或许值得我们对用户画像的运用重新进行思考。
2. 过于主观的代入
有这样一种用户画像，它完全源于设计师对问题的主观看法与偏见。更为通俗地讲，是设计师先主观地提出了设计概念，然后创建用户画像去支撑其概念，美其名曰「以用户为中心」的设计。这种类型的用户画像由 Jones 等学者提出，他们称其为「promotional personas」。Jones 等在伊利诺伊大学香槟分校教授设计类的课程，在长达 5 年的时间里，通过对学生们在课程所创建的用户画像进行观察，他们对用户画像的几种模式进行了归类，而「promotional personas」就被归在了「bad personas」这一类别中。Jones 等还举出了一个他们在课程中观察到的例子：有学生设计了一款闹钟，这款闹钟可以让用户以天为单位自定义规划一整个月的闹铃时间。然后她做了一些调研，调研后发现身边朋友们的作息都很规律，在时间管理工具上的使用频次也较低，因此不太可能去用她所设计的那款闹钟。然而，她之后却提出了一个与调研结果完全相反的用户画像，该用户画像每天醒来的时间都很不同，而且经常由于睡过头而错过重要的事情。
设计师凭借自己的直觉与经验去创建用户画像这种方式，尽管也能在设计中起到一定作用，但如果将用户画像完全当做支撑主观设计概念的工具，甚至不惜背离调研结果，用户画像就彻底地沦为一种形式了。这样的用户画像，对整个设计过程都是有害无益的。
3. 无法取代真实用户的参与
既然用户画像能作为真实用户的代表，那么，对于参与式设计（participatory design）这种需要真实用户直接参与的方式，用户画像是否能替代真实用户呢？Bodker 等学者基于电子政务的项目，探究了用户画像对参与式设计是否有支撑作用。通过 4 个案例进行观察，Bodker 等发现：尽管用户画像能促进设计师在实际的参与式设计开始之前去更多地聚焦于用户，但在参与式设计的过程中，并不能让设计师更贴近真实用户的处境，反而可能分散设计师的注意力，让其偏离对真实用户参与情况的关注。这样一来，也无法说明用户画像本身对参与式设计具有支撑作用。因此，如果要采用参与式设计，在条件允许的情况下，建议还是让真实用户参与其中，用户画像可能并不能取代真实用户。
尽管上文总结和归纳了用户画像的种种问题与局限，但这些并不能否认用户画像作为一种工具，对设计过程所起到的帮助。问题和局限的提出，旨在帮助我们更多地去理解这一工具，细分它适合的设计场景，探索能否结合其他工具以弥补它的短板和不足，从而达到更好的使用效果。
文章来源：优设 作者：陈梦蝶 驴妈妈UED
CSS 函数大家多多少少都使用过，比如 rgb() , rgba() , linear-gradient(), radial-gradient() , 等。
今天小编给大家介绍几个特殊的 css 函数。
attr() 这是一个很强的函数，他可以让数据传输到你的 css 中，不需要借助其他东西。
用法：
<style>
div::before {
content : attr(data-abc);
}
</style>
<div data-abc='我是attr'></div>
calc() 用与动态计算长度值
给大家展示快速让子盒子在父盒子中居中的另一种方法：
<style>
.father {
position: relative;
width: 300px;
height: 300px;
background-color: pink;
}
.child {
position: absolute;
/ 这里的 50px 为子盒子宽（高）的一半 /
top: calc(50% - 50px);
left: calc(50% - 50px);
width: 100px;
height: 100px;
background-color: blue;
}
</style>
<div class="father">
<div class="child"></div>
</div>
cubic-bezier() 定义了一个贝塞尔曲线(Cubic Bezier)。在这我就不多描述了，关于贝塞尔曲线，感兴趣的同学可以自行去了解。
var() 用于插入自定义的 css 属性值。
用法：和 sass，less 中定义变量的语法相似
<style>
:root {
--abc-- : red;
}
div {
width: 100px;
height: 100px;
background-color: var(--abc--);
}
</style>
<div></div>
counters() 这是一个古老但实用的属性，用与 css 中计数
用法：
counter-reset : item 1；
给定计数器 item 的初始值1，也可用与复位。参数 ‘item’ 为计数器的名称，后面的 ‘1’ 参数如果不写，默认是 0。
counter-increment: item 2;
设定当一个 item 计算器发生时计数器增加的值。参数 ‘2’为每次计数增长 2。
counters(item,’-’);
写在content中，显示计数器的值，‘-’ 设定俩计算器拼接时中间的符号为’-‘。它还有第三个参数，是list-style-type , 与 css 属性 list-style-type 是一模一样的。用与设定计数器以什么形式显示（阿拉伯数字，英文大小写，等）
<style>
ul {
counter-reset: item 1;
}
li:before {
counter-increment: item 2;
content: counters(item, "-");
}
</style>
<ul class="test">
<li> html
<ul>
<li> css</li>
<li> js</li>
</ul>
</li>
<li> Node</li>
<li> ts</li>
</ul>
bootstrap-multiselect动态加载数据，首先要引用bootstrap-multiselect.css和bootstrap-multiselect.js
<select id="demo" name="demo" multiple></select>
JS代码
$("#demo").multiselect({
// 自定义参数，按自己需求定义
nonSelectedText : '--请选择--',
inheritClass : true,
maxHeight : 350,
includeSelectAllOption : true,
numberDisplayed : 5,
//下拉回调函数
onDropdownShow : function(event) {
$.ajax({
url : "${ctx}/xx/xx",
async : false,
type : "get",
dataType : "json",
success : function(data) {
var mark = new Array();
for (var i = 0; i < data.length; i++) {
mark.push({
value : data[i].markId,
label : data[i].markName
});
}
$("#demo").multiselect('dataprovider', mark);
}
})
},
});
获取选中的值的集合
var selectList = $('#demo option:selected');
1
遍历集合得到选中的value和label
for (var i = 0; i < selectList.length; i++) {
value = siteList[i].value;
label = siteList[i].label;
}
希望这篇文章可以帮助到你
一、首先找到第一次发起网络请求的地址，将服务器返回set-cookie当全局变量存储起来
wx.request({
......
success: function(res) {
console.log(res.header);
//set-cookie:PHPSESSID=ic4vj84aaavqgb800k82etisu0; path=/; domain=.fengkui.net
// 登录成功，获取第一次的sessionid,存储起来
// 注意：Set-Cookie（开发者工具中调试全部小写）（远程调试和线上首字母大写）
wx.setStorageSync("sessionid", res.header["Set-Cookie"]);
}
})
三、后台获取cookie中的PHPSESSID，将PHPSESSID当作session_id使用
<?php
// 判断$_COOKIE['PHPSESSID']是否存在，存在则作session_id使用
if ($_COOKIE['PHPSESSID']) {
session_id($_COOKIE['PHPSESSID']);
}
session_start();
echo session_id();html5的新特点
1.语法更简单
a) 头部声明
<!doctype html>
b) 简化了字符集声明
<meta charset="utf-8">
2.语法更宽松
a) 可以省略结束符的标签
li、dt、dd、p、optgroup、option、tr、td、th
b) 可以完全省略的标签
html、head、body
3.标签语义化
增加了很多标签，在作页面的时候更加具有语义（定义了一些原本没有语义的div模块为有鲜明结构的语义模块）
a) <header>标记定义一个页面或一个区域的头部
b) <nav>标记定义导航链接
c) <article>标记定义一篇文章内容
d) <section>标记定义网页中一块区域
e) <aside>标记定义页面内容部分的侧边栏
f) <footer>标记定义一个页面或一个区域的底部
语义化标签图示
4.表单新增常用属性------要求掌握
required：必填
placeholder：输入内容提示
autofocus：自动获取焦点-----自动帮我们将光标点进去
<form method="post" action="http://www.baidu.com">
<!-- required 必填，必须的 -->
<!-- 自动获取焦点----自动将光标定位到表单中 -->
<input type="text" placeholder="请输入用户名" autofocus="autofocus" required="required" />
<input type="submit" />
</form>
5.input新增type属性值
a) type=“email”，文本框中只能输入email地址
b) type=“date”，日期控件
c) type=“time”
d) type=“month”
e) type=“week”
f) type=“number”，唤醒数字键盘
g) type=“range”，滑块
h) type=“color”
最近在做一个手机站，要求点击分享可以直接打开微信分享出去。而不是jiathis，share分享这种的点击出来二维码。在网上看了很多，都说APP能唤起微信，手机网页实现不了。也找了很多都不能直接唤起微信。
总结出来一个可以直接唤起微信的。适应手机qq浏览器和uc浏览器。
下面上代码，把这些直接放到要转发的页面里就可以了：
html部分：
-
<script src="mshare.js"></script>//引进mshare.js
-
<button data-mshare="0">点击弹出原生分享面板</button>
-
<button data-mshare="1">点击触发朋友圈分享</button>
-
<button data-mshare="2">点击触发发送给微信朋友</button>
js部分：
-
<script>
-
var mshare = new mShare({
-
title: 'Lorem ipsum dolor sit.',
-
url: 'http://m.ly.com',
-
desc: 'Lorem ipsum dolor sit amet, consectetur adipisicing elit. Quaerat inventore minima voluptates.',
-
img: 'http://placehold.it/150x150'
-
});
-
$('button').click(function () {
-
// 1 ==> 朋友圈 2 ==> 朋友 0 ==> 直接弹出原生
-
mshare.init(+$(this).data('mshare'));
-
});
-
</script>
下面是mshare.js的代码分享，把这些代码新建一个js文件放进去，然后在页面中引进就ok了。
-
/**
-
* 此插件主要作用是在UC和QQ两个主流浏览器
-
* 上面触发微信分享到朋友圈或发送给朋友的功能
-
*/
-
'use strict';
-
var UA = navigator.appVersion;
-
-
/**
-
* 是否是 UC 浏览器
-
*/
-
var uc = UA.split('UCBrowser/').length > 1 ? 1 : 0;
-
-
/**
-
* 判断 qq 浏览器
-
* 然而qq浏览器分高低版本
-
* 2 代表高版本
-
* 1 代表低版本
-
*/
-
var qq = UA.split('MQQBrowser/').length > 1 ? 2 : 0;
-
-
/**
-
* 是否是微信
-
*/
-
var wx = /micromessenger/i.test(UA);
-
-
/**
-
* 浏览器版本
-
*/
-
var qqVs = qq ? parseFloat(UA.split('MQQBrowser/')[1]) : 0;
-
var ucVs = uc ? parseFloat(UA.split('UCBrowser/')[1]) : 0;
-
-
/**
-
* 获取操作系统信息 iPhone(1) Android(2)
-
*/
-
var os = (function () {
-
var ua = navigator.userAgent;
-
-
if (/iphone|ipod/i.test(ua)) {
-
return 1;
-
} else if (/android/i.test(ua)) {
-
return 2;
-
} else {
-
return 0;
-
}
-
}());
-
-
/**
-
* qq浏览器下面 是否加载好了相应的api文件
-
*/
-
var qqBridgeLoaded = false;
-
-
// 进一步细化版本和平台判断
-
if ((qq && qqVs < 5.4 && os == 1) || (qq && qqVs < 5.3 && os == 1)) {
-
qq = 0;
-
} else {
-
if (qq && qqVs < 5.4 && os == 2) {
-
qq = 1;
-
} else {
-
if (uc && ((ucVs < 10.2 && os == 1) || (ucVs < 9.7 && os == 2))) {
-
uc = 0;
-
}
-
}
-
}
-
/**
-
* qq浏览器下面 根据不同版本 加载对应的bridge
-
* @method loadqqApi
-
* @param {Function} cb 回调函数
-
*/
-
function loadqqApi(cb) {
-
// qq == 0
-
if (!qq) {
-
return cb && cb();
-
}
-
var script = document.createElement('script');
-
script.src = (+qq === 1) ? '//3gimg.qq.com/html5/js/qb.js' : '//jsapi.qq.com/get?api=app.share';
-
/**
-
* 需要等加载过 qq 的 bridge 脚本之后
-
* 再去初始化分享组件
-
*/
-
script.onload = function () {
-
cb && cb();
-
};
-
document.body.appendChild(script);
-
}
-
/**
-
* UC浏览器分享
-
* @method ucShare
-
*/
-
function ucShare(config) {
-
// ['title', 'content', 'url', 'platform', 'disablePlatform', 'source', 'htmlID']
-
// 关于platform
-
// ios: kWeixin || kWeixinFriend;
-
// android: WechatFriends || WechatTimeline
-
// uc 分享会直接使用截图
-
var platform = '';
-
var shareInfo = null;
-
// 指定了分享类型
-
if (config.type) {
-
if (os == 2) {
-
platform = config.type == 1 ? 'WechatTimeline' : 'WechatFriends';
-
} else if (os == 1) {
-
platform = config.type == 1 ? 'kWeixinFriend' : 'kWeixin';
-
}
-
}
-
shareInfo = [config.title, config.desc, config.url, platform, '', '', ''];
-
// android
-
if (window.ucweb) {
-
ucweb.startRequest && ucweb.startRequest('shell.page_share', shareInfo);
-
return;
-
}
-
if (window.ucbrowser) {
-
ucbrowser.web_share && ucbrowser.web_share.apply(null, shareInfo);
-
return;
-
}
-
}
-
/**
-
* qq 浏览器分享函数
-
* @method qqShare
-
*/
-
function qqShare(config) {
-
var type = config.type;
-
//微信好友 1, 微信朋友圈 8
-
type = type ? ((type == 1) ? 8 : 1) : '';
-
var share = function () {
-
var shareInfo = {
-
'url': config.url,
-
'title': config.title,
-
'description': config.desc,
-
'img_url': config.img,
-
'img_title': config.title,
-
'to_app': type,
-
'cus_txt': ''
-
};
-
if (window.browser) {
-
browser.app && browser.app.share(shareInfo);
-
} else if (window.qb) {
-
qb.share && qb.share(shareInfo);
-
}
-
};
-
if (qqBridgeLoaded) {
-
share();
-
} else {
-
loadqqApi(share);
-
}
-
}
-
/**
-
* 对外暴露的接口函数
-
* @method mShare
-
* @param {Object} config 配置对象
-
*/
-
function mShare(config) {
-
this.config = config;
-
this.init = function (type) {
-
if (typeof type != 'undefined') this.config.type = type;
-
try {
-
if (uc) {
-
ucShare(this.config);
-
} else if (qq && !wx) {
-
qqShare(this.config);
-
}
-
} catch (e) {}
-
}
-
}
-
// 预加载 qq bridge
-
loadqqApi(function () {
-
qqBridgeLoaded = true;
-
});
-
if (typeof module === 'object' && module.exports) {
-
module.exports = mShare;
-
} else {
-
window.mShare = mShare;
-
}
好了，这样就可以直接唤起微信进行分享啦
蓝蓝设计的小编 http://www.lanlanwork.com