兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
闲鱼发闲置功能接入AI，只需上传商品图片就可以直接生成描述文案，极大帮助用户简化发布流程
1. 零门槛发布，降低发布时间成本
解决非专业用户 “不会写文案、不懂专业术语” 的痛点，自动提取商品特征，组合成规范文案；相比传统发布流程的耗时编辑文案、核对信息，更高效快捷。
2. 优化内容，提升交易转化
自动生成符合当前市场热点的文案表述，更能多文风转换，一键转为趣味的 “抽象文学”“黛玉文学”等，提升内容点击率。
支付宝的首页Banner通过游戏化的包装，快速吸引注意力，驱动用户主动点击探索，高效地为活动页面引流。
1. 互动机制强化用户参与感
采用悬念式互动设计，button以 “猜猜是什么” 这类问答形式，激发用户好奇心，通过游戏化场景的营造，降低参与门槛，驱动用户主动点击探索。
2. 场景氛围营造提升吸引力
在以功能入口为主的首页，该模块具有游戏化趣味性的氛围营造，从视觉上差异化的呈现，相比传统的静态广告位，更能有效抓住用户眼球，高效地为活动页面引流。
当有中转单的用户在点击退票时，用挽留浮层及时给用户弹出更优的解决方案，并在方案中量化利益点，同时保证原有票的安全感。整体通过 “先抓痛点→再给解决方案→最后引导操作” 的路径，优化了用户出行体验。
1. 量化利益点
除了直达更方便之外，直达还有更省时间、金钱，保底票免费退等更多的利益点
2. 有兜底有安全感
用当前的中转作为保底，先抢票，抢到了还能再退票。让用户安心下单，在未抢到心仪票的时候能有中转的替补票，可以缓解用户的焦虑情绪，有兜底的保障安全感
通过一个巧妙的互动行为“摇动手机”，降低用户对会员充值广告的反感。
1. 提升用户参与感与趣味性
“摇一摇”互动将被动观看广告转变为主动参与，用户通过简单的物理动作即可触发折扣，这种即时反馈机制增强了趣味性，降低了传统广告的侵入感。
2. 降低付费决策的心理门槛
通过互动行为展示折扣，巧妙地将付费流程包装成一种“奖励”而非强制推销。用户感受到的是“主动获取优惠”的成就感，而非被广告打扰的抵触情绪，从而更愿意接受付费选项。
通过拟物化的卡牌堆叠形态，将传统的平面信息流转变为具有空间纵深感和探索趣味的交互式叙事焦点
1. 视觉层次突破传统束缚
通过卡片堆叠、倾斜，在二维屏幕上创造出三维空间感。不对称的布局打破了传统设计的呆板，赋予界面动感与活力，能有效抓住用户视线，对抗“横幅盲视效应”
2. 建立拟物化的趣味交互
模拟物理世界卡牌的操作体验，配合流畅的滑动动画，让用户产生"翻阅卡片"的愉悦感，这种情感化设计能显著提升用户的操作满足感和停留时长
3. 内容暗示激发探索行为
堆叠效果露出部分内容作为预览，能有效刺激用户的好奇心，主动进行滑动探索，提升内容消费深度
该设计通过 “贴合用户习惯的交互 + 强引导 + 积分激励” 的组合策略，实现签到转化与用户留存
1. 交互设计贴合用户固有习惯
采用下拉触发模式，无需额外学习成本，降低用户参与签到的操作门槛，提升即时转化效率
2. 视觉设计强化引导与目标感知
以金币掉落清晰的视觉元素突出金币中心入口，让用户快速捕捉核心功能，减少寻找成本，缩短 “看到 - 参与” 的路径
3. 激励设计构建留存闭环
用 “金币” 作为即时激励，满足用户即时反馈的心理需求，驱动次日复访，同时联动积分体系，将单次签到转化为长期行为
本期的设计分享就到这里啦。
文章中的案例与思考来自于UED同学的日常分享。
后续我们将持续深度体验产品，挖掘更多值得分享、学习的设计案例。努力将其中的方法理论应用到后续的产品设计中。
愿我们的努力为你带来更好的体验。下次见。
转载：优设
兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
作者：PONEPENG
来源：站酷
蓝蓝设计(www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。
关键词：UI咨询、UI设计服务公司、软件界面设计公司、界面设计公司、UI设计公司、UI交互设计公司、数据可视化设计公司、用户体验公司、高端网站设计公司
银行金融软件UI界面设计、能源及监控软件UI界面设计、气象行业UI界面设计、轨道交通界面设计、地理信息系统GIS UI界面设计、航天军工软件UI界面设计、医疗行业软件UI界面设计、教育行业软件UI界面设计、企业信息化UI界面设计
业内有很多人觉得手势交互没必要拿出来深究，觉得用户使用产品的过程中，自然而然就会去使用拇指，进行手势操作。但这种说法，就跟「用户心理模型」类似。当然，对于用户来说没必要深究手势交互，但作为设计师，如果不了解其背后的逻辑，那么就无法解决产品设计背后的一些问题。
所以我们今天，好好聊一聊手势交互这件事。你会发现，原来你以往观察或以为的设计问题，都是手势交互在作祟。
我们以前经常听到「以用户为中心做产品设计」这句话，意思是产品需依附于目标用户的真实场景来设计。与此同时，其实还有一句话在提醒着交互设计师如何做产品设计，就是「以触摸屏为中心做产品设计」。
为什么呢？因为用户从始至终都是在跟触摸屏做接触，不管换了什么设备，他们都是要通过屏幕与产品进行交互的。
我们可以在这里思考一下手势的意义。
手势的出现改变了什么？可以回想一下 iPhone 4 发布的时候，当看到这样一台屏幕上没有任何按键的设备，是不是会觉得不可思议？键盘，电话接听按键等都消失不见了。
人们在使用 iPhone 这样的产品时，不再需要去强行记忆任何固体按键。触摸屏与手势的结合，帮助我们隐藏不必要的元素，帮助用户聚焦于内容，在有限的物理空间获得更多的信息。
所以用户通过触摸屏与产品进行交互，跟通过键盘按键与屏幕进行交互是完全不同的。手势交互更自然且更。
手势操作对我们来说如此自然和直观的主要原因是因为它们类似于与真实对象进行直接交互。譬如你用遥控器控制电视上的按键，需要通过上下左右这样的操作来定位指示器，而触摸屏直接就可以通过手指点击内容进行操作。这是完全不同的概念。
综上所述，我们能知道，手势的三个要素：简洁、易用、直观。
所以我们通过一些常见的手势行为，就可以在产品界面上很轻松的完成任务。
常见的手势行为：
当然，我们经常也会遇到一些背离手势交互的产品设计，虽然也是点击、拖动等等，但操作起来总是不那么顺心。这里面有一个关键点就是，手势直观性。
有数据表明，苹果的 3D Touch 使用率非常低，就是因为直观性太差，用户不知道通过这个操作能带来什么结果，且使用它需要长按，经常会同时呼出「卸载」，那么效率也就会降低。久而久之，用户就不去使用了。
正面例子如下图，滑动与文案结合。
这样一看，用户马上就能知道这个操作行为如何触发，紧接着就产生行动，然后会反馈结果。
这也是手势交互的核心：触发，行动，反馈。
对比 3D Touch，触发没有提示，行动后时常有两种反馈结果，相比起来就不那么友好了。
除了上面聊的这些，手势交互还能从另一方面来提升效率，就是拇指操作区域。
我们都知道，现在手机屏幕越来越大，甚至比最早屏幕大了一倍以上。但是很多设计师并没有转换思维，跟进这个趋势的变化。
这里给大家普及一个知识：大部分人误以为，手指在屏幕上的热区是永恒不变的，但其实手指热区会根据设备的变大而缩小。因为手掌支撑设备的重心靠后走了，所以拇指操控屏幕的范围也就变小了。如下图。
结果是，手机屏幕变大，双手持机的用户变多，但依然还有 75％ 的用户是使用拇指来触摸屏幕的。因此，术语「拇指驱动设计」应运而生。
我们上面说到，在使用一些产品的时候，经常会遇到使用起来不顺心的情况，然后说了「手势直观性」的概念。但这里，还有个更重要的原因，就是「拇指操作区域」。
拇指操作区域被分为三块内容，分别是：易于触达，难以触达，以及介于两者之间的区域。
看下图。
所以在设计界面时，要注意界面的主要操作元素是否处于用户易于触达的范围之内。
如果你仔细观察并思考过，也会发现，iOS 的产品界面中，「返回」按钮就位于「难以触达」的区域。原因是产品人员本身也不想用户返回或退出，而是让用户聚焦于当前页面，想要返回，那就需要付出一点成本，什么成本？操作成本。
有人会说，由于 iOS 可以从手机的左边缘向右侧轻扫以获得返回效果，因此在大多数 iOS 产品中，返回都不需要太大的操作成本。但是，并不是所有 iPhone 用户都知道这一点，也不是所有产品都支持这一特性的。而且手势交互的进化本来也就是为了提升用户操作的效率，所以本质上他们并不矛盾，只是相比以前，我们现在的操作更快了。并且「右滑」返回，本身在手势操作中相比「点击」也是更具操作成本的。
当了解了手势的一些意义，以及拇指操作区域对于产品设计的重要性之后，我们就可以通过一些案例来做一个全局分析了。
1. 内容在上，操作在下
许多人设计 App，但是没人研究过 App 为什么要这么设计。
比如，为什么起初要把标签栏放底下呢？关于这个问题，当初我也是问了许多人，而基本都只是说这是官方设计规范。这相当于是一句废话。
通过翻阅多方资料，我发现在工业设计领域有一条重要的基本设计原则：内容在上，操作在下。
比如在使用电脑的时候，操作在下意味着使用者在操作过程中，手指始终处于界面下方，而内容在上面，就不会出现手指遮挡内容的情况。
如下图的键盘操作提示：
基于此，相信你也知道为什么标签栏在下方了吧？
另外，为什么 iOS 设计规范建议将「编辑」按钮放置在界面右/左上方的位置呢？
界面右/左上角的位置对拇指来说显然是不友好的。然而，这样做的原因也是显而易见的：编辑功能会让数据发生变化。将这类控件放在难以操作的位置上（与左上角的返回是一个道理），就是一种防御性的设计策略，可以在一定程度上避免因为太容易产生误操作而导致的破坏性的结果。
通过这一小段之前聊过的内容，你们会发现，手势与拇指操作其实在驱动着产品设计。下面我们来聊个大的案例。
汉堡包菜单，也就是侧边栏导航，Facebook 早期测试显示侧边栏导航让用户使用率降低了一半。
我们一起来看看市面上给出的三类说法。
1. 可见性太低
默认状态下，用户是看不见侧边栏的，除非点击了侧边栏的弹出按钮。所以这种情况下，里面的功能都是用户脑袋里已知的，但很可能都想不起来。比如，现在你回想一下知乎底部 5 个标签分别是什么？或者微信右上角「+」里面有哪些功能？是不是要想一会儿，才能记起来？甚至还是想不起来。
之前我在文章里写过，用户对于功能的使用一定是「所见即所得」，而不是「心向往之」。用户只会注意自己看到的信息，而不是凭借记忆或想象来使用产品。
底部标签栏就很好的解决了汉堡包菜单的「可见性」问题。
2. 效率较低
效率较低主要在于操作频率，大家看下面两组图的对比。
第一张图，当用户从首页进入到个人信息页面，只需要两步；而第二张图，则要三步。
这里多一步看起来似乎影响不大，但如果现在要从个人信息页面到「标签 3」的话，第一张图也只需要两步，第二张图还是需要三步，当频繁去使用这样的产品后，用户的整体效率就会下降，体验也会随之降低。
3. 与平台模式冲突
大家应该知道，在 iOS 的操作页面中，通过手势可对 tab 进行左右切换，而侧边栏除了通过点击菜单按钮展开之外，也可以通过右滑弹出。这里面有什么冲突呢？看下图。
当页面聚焦在「标签 2」时，右滑除了能回到「标签 1」，同样也很可能会切出侧边导航栏。
这样的手势冲突，导致页面层级与功能导航的优先级混乱了。
无论是导航还是控件，当它们组成一个页面后，它们的操作就会有优先级。比如下面这个例子。
如果你对标红的分段控件比较熟悉，就知道，它是可通过屏幕滑动进行切换的。但是在「短信」里，它是不能通过滑动屏幕进行切换的，因为用户可对单条信息进行左滑做删除或其他操作。所以当页面操作模式存在矛盾时，我们会将子层级操作优先于父层级操作。
譬如你进入朋友圈，是不能马上回到首页的，这时候页面层级较深，产品人员要将用户聚焦于页面本身，如果直接能返回到首页，页面层级和产品架构就会混乱。
类似的例子还有很多，我这里就不继续列举了。
所以从「短信」的例子可以看出，当控件与控件之间的手势发生冲突时，我们要考虑优先级，将内容优先于页面来处理。那么回到上面的例子，分段控件与汉堡包菜单的手势发生冲突时，很明显我们要优先分段控件的操作，而禁止掉汉堡包菜单的右滑手势。结果就是，效率又低了。
4. 小结
这三类，如果你认真思考里面的关系，其实就会发现，它们的共通点就是与拇指的联系过于被动或直接被切断了。
它们的核心点就是拇指与触摸屏的关系。
如果你现在还不能深刻理解汉堡包菜单的劣势，那就想一下去看一下现在的产品，其中「我的」、「个人中心」或「更多」其实都是变相的汉堡包菜单。
在「我」这个标签页里，这一系列功能列表，无非就是另一种模式的汉堡包菜单，只是这里呈现的都是不重要的功能，并不影响用户使用这个产品。回想一下，你是不是很少，甚至从来没用过这里的某几个功能？再跟手势结合，就会发现，「我」所处区域并不是容易点击的区域，这就是它效率低下的原因了。现在能懂了么？
当传统的确认弹窗逐渐被手势操作取代，大家就应该察觉到：以往从电脑迁移到移动设备上的交互行为已逐渐被改善。
我曾经写过一篇文章，叫「取消按钮的设计逻辑」，讲了「左取消，右行进」这个原理。意思就是当我们在设计弹框的时候，用户已经习惯这样的操作路径，所以不要轻易更换位置以混淆用户的认知。再从手势的角度来说，就是右边更容易点击。
后来有同学说到，但是有些特殊场景，譬如删除资料，而产品人员不希望用户删除，于是把删除放在左边，取消放在右边。毕竟右边更容易点击，所以位置换了会比较合理。
这是错的！
我们不能通过改变用户使用产品的常识来将产品人员的想法置于用户之上。当用户已经形成「左取消，右行进」的认知之后，违反这样的一致性，去换位置是很危险的。所以出现了 action sheet，来解决一些产品关于 alert 无法解决的问题。
如图。
大家要记住的是，当页面逻辑与手势操作产生逻辑冲突时，我们不是去否定以前已经被验证且正确的内容，而是通过创新，来解决这个冲突。这就是拇指驱动设计的一种方式。
包括我们以前在移动设备上选择删除某项数据，都会弹出警告框，询问我们是否确认删除。这种方式会打断我们的操作行为，久而久之，用户已经对此交互方式习以为常，或者说免疫了，但这种弹框的方式始终被认为是不好的一种交互手段。所以侧滑删除，已经被更多产品功能用来取代没必要弹框的操作。
也许很多人没思考过底层原因，或者仅仅只是觉得其相比弹框显得更友好。其实这个行为是基于手势交互做了相应的优化，让用户操作起来更加方便。
到了这里，我再举个所有人都熟悉的例子，就是轮播图了。
轮播图最早出现于网页端，后来被大量商家模仿，以至于到移动端还备受各产品设计人员的欢迎。但其实很多人对轮播图的使用方法都是错误的。
下面来看轮播图与手势的关系。
试想：你的轮播图有 6 张 Banner，你要翻到第 4 张，无论是往前翻还是往后翻都要产生 3 次交互行为。而大部分产品的用户在界面停留的时间不会这么久，更不会看完你 Banner 的内容。以至于有研究表明，大部分产品里，除了第一张 Banner 的点击率能达到 83% 之外，其余的点击率都非常低。
有人说可以点击下面的原点指示器做跳转，这么小的点，你觉得点击它现实么？所以手势交互与轮播图是相互矛盾的一种设计方式。
所以当运营策划了一个活动，而你就往顶部的轮播图里塞，这个行为就已经注定这个活动的用户参与度是很低的了。除了个别电商产品，他们以卖广告位给商家作为盈利点，但即便如此，我相信这个广告位除了第一张图的点击量稍高外，其他图片的点击量相对于产品本身的用户体量比较而言还是很低的。这也是为什么部分产品把轮播图规则改为用户进入首页随机展示轮播图页面，而不是强制指定于显示第一张的原因。
毕竟轮播图在顶部，用户需要通过拇指长时间的在「延伸区域」进行操作，那么使用率自然就降低了。
如果你的产品有很多活动是在同时期进行的，那么我给部分产品的建议是放一个活动主题入口，如下图。（当然，这要视情况而定，并不是通用的。）
我们现在看到的搜索框基本都是放在屏幕顶部。
为什么呢？
市面上对这个问题的解释是这样的：用户已经被现在的产品训练得在界面的顶部必须看到一个搜索框，设计师打破这个常规就要承担风险。
看完这篇文章，你就已经知道，对于用户来说，由于屏幕顶部离拇指很远，处于难以触达的区域，在体验上很不好。所以搜索框成了认知上应该在顶部，但操作体验上又不应该在顶部的一个设计。
但是回想一下，会发现大多数 App 的主要内容都是位于易于触达的区域。所以当看到高德地图把搜索框移动到下面来之后，就能知道，拇指驱动设计的概念被越来越多的人认识到其重要性。
地图类产品把搜索框移到下面来的首创应用不是高德，应该是 Lyft。
瞧，拇指驱动设计，多酷~
《上瘾》里有句话：当人们不由自由地做出下一个举动时，新的习惯就会成为他们日常生活的一部分。
当手势充分地发挥了作用，辅助用户操作或实现功能，它就成了用户不可分割的一部分。
今天通过对手势意义的解读，以及拇指驱动设计的解析，再加上这些案例的拆解，我相信你能更好地理解为什么手势交互这么重要了。
交互设计师对于「触摸屏」，必须有深刻的认识，才能理解设计背后的逻辑。
如果这篇文章对你有帮助，记得点个赞，后面我好持续输出。
文章来源：优设
如果您想订阅本博客内容，每天自动发到您的邮箱中， 请点这里
先贴图，需要实现的效果是这样的。
实现思路有两个：
1、用6个input，输入一个数字后将focus给下一个输入框。
2、用一个input和6个span，input隐藏，用span显示。
现在大部分都是使用的第二种方法。（当然，如果你能说服产品也可以只用一个普通的input输入框，就什么都不用考虑了）
两种方案遇到的坑，以及优缺点，如下：
方案一：6个input。
主要就是用js切换focus，在安卓是相当流畅的，但是在ios会严重卡顿，简直逼死强迫症。
HTML：
<div class="divYZM">
<!-- onpropertychange是为了避免在ios中oninput方法不被触发 -->
<input id="check_1" class="numDiv" type="number" oninput="inputNext(check_1)" onpropertychange="inputNext(check_1)"/>
<input id="check_2" class="numDiv" type="number" oninput="inputNext(check_2)" onpropertychange="inputNext(check_2)"/>
<input id="check_3" class="numDiv" type="number" oninput="inputNext(check_3)" onpropertychange="inputNext(check_3)"/>
<input id="check_4" class="numDiv" type="number" oninput="inputNext(check_4)" onpropertychange="inputNext(check_4)"/>
<input id="check_5" class="numDiv" type="number" oninput="inputNext(check_5)" onpropertychange="inputNext(check_5)"/>
<input id="check_6" class="numDiv" type="number" oninput="inputNext(check_6)" onpropertychange="inputNext(check_6)"/>
</div>
JS：
function inputNext (id){ // 传过来的id是个对象
var index = Number(id.id.split("_")[1])
if (id.value.length < 1) { // 删除
id.value = ''
if (index > 1) {
var preId = 'check_' + Number(Number(index) - 1)
document.getElementById(preId).focus()
return false
}
} else {
if(id.value.length>1) {
var nextValue = id.value.slice(1, 2)
var nextId = 'check_' + Number(Number(index) + 1)
id.value = id.value.slice(0, 1)
if ((index+1) <= 6) {
document.getElementById(nextId).value = nextValue
document.getElementById(nextId).focus()
}
}
}
}
PS：我这里写的删除方法是有问题的，这也是我果断放弃这种方案的原因之一。
如果正常输入，然后删除是可以的。
但是输入几个数后，先点击中间的框删除一个数字，再回到最后，便只能将中间到最后的这几个删掉，最前面的还需要手动点一下得到focus才能删除。
这对用户来说，简直太不友好了。。。
CSS：
.divYZM{
width: 90%;
margin: 0 auto;
height: 100px;
background-color: rgba(74, 35, 35, 0.42);
}
.numDiv{
display: block;
width: 10%;
float: left;
border-radius: 5px;
text-align: center;
line-height: 60px;
font-size: 20px;
font-weight: 900;
color: red;
background-color: white;
height: 60px;
border: 0;
padding: 0;
margin: 0;
margin-left: 5.7%;
top: 20px;
position: relative;
caret-color: transparent;
}
这里遇到的坑，举例一个。
input限制长度的属性maxlength
a、与如下两种配合使用（tel也可以限制）
<input type="text"> 或者
<input type="password">
b、当type为number时不起作用。这时需要用js控制。
<input type="number" oninput="if(value.length>5) value=value.slice(0,5)" />
注意：此外，tel类型的input在ios上会调出全数字键盘，而number类型的input则会调出带有标点符号的键盘。
方案二：1个input和6个span。
隐藏input，用span显示内容。大坑就是，何种情况下能调起ios的软键盘呢？
先贴一下我刚开始的input样式。
width: 0;
height ：0；
border: 0;
padding: 0;
margin: 0;
第二种
display:none;
简单粗暴，结果就是，ios木得反应。为啥呢，我想不通。
后来在晚上睡觉的时候我在想，我这两种方式input都么有占位啊，那是不是占位了就可以了呢？
经测果然是可以的（默默谴责自己懒了一下，没有将不隐藏input的情况，在手机上进行测试）。
接下来贴正确代码。
CSS：
#yzm{
width: 0;
border: 0;
padding: 0;
margin: 0;
height: .44rem;
position: absolute;
outline: none;
color: transparent;
text-shadow: 0 0 0 transparent;
width: 300%;
margin-left: -100%;
}
#yzmTable {
width: 90%;
margin: 0 auto;
height: 100px;
/* border: 1px solid red; */
background-color: rgba(74, 35, 35, 0.42);
/* opacity: 0.1; */
}
#yzmTable span {
display: block;
width: 10%;
float: left;
border-radius: 5px;
text-align: center;
line-height: 60px;
font-size: 20px;
font-weight: 900;
color: red;
background-color: white;
height: 60px;
margin-left: 5.7%;
top: 20px;
position: relative;
}
这里对input的样式也包括对光标的隐藏，我在第一种方案中对光标未进行处理，因为在看到ios的卡卡卡之后果断放弃了第一种方案。
HTML:
<input id="yzm" type="tel" maxlength="6" value="" oninput="yzmInsert()">
<div id="yzmTable">
<span id="s_1" onclick="intoYzm(1)"> </span>
<span id="s_2" onclick="intoYzm(2)"> </span>
<span id="s_3" onclick="intoYzm(3)"> </span>
<span id="s_4" onclick="intoYzm(4)"> </span>
<span id="s_5" onclick="intoYzm(5)"> </span>
<span id="s_6" onclick="intoYzm(6)"> </span>
</div>
JS:
function intoYzm(index) {
var ele = document.getElementById("yzm")
ele.focus()
}
function yzmInsert() { // input内容改变时触发
for (var i = 1; i <= 6; i++) {
var nextId = 's_' + i
document.getElementById(nextId).innerHTML = ' '
}
var yzm = document.getElementById("yzm").value
var yzmArr = yzm.split('');
for (var i = 0; i < yzmArr.length; i++) {
const num = yzmArr[i];
var id = 's_' + Number(i + 1)
document.getElementById(id).innerHTML = ' ' + num + ' '
}
}
// 收起软键盘的方法，点击除了输入框之外的其他区域就收起软键盘
$('body').on('touchend', function(el) {
if(el.target.tagName != 'SPAN') {
$('yzm').blur()
}
})
在第二种方案中有两个地方注意下：
a、在js方法中加了对全局中6个span标签（即六个输入框）之外区域点击事件的监听，用以收起软键盘，方法如下。
$('body').on('touchend', function(el) {
if(el.target.tagName != 'SPAN') {
$('yzm').blur()
}
})
（比较粗糙，如果页面中还有别的部分就比较受影响了，可以自行改进）
b、在隐藏的input中添加了onclick方法，如下并且在其中用了blur方法使得此输入框失去焦点。为什么这么做呢？
<input id="yzm" type="tel" maxlength="6" value="" oninput="yzmInsert()" onclick="this.blur();">
因为此处的隐藏并非真正的隐藏，而是透明化处理，边框包括光标全部透明化，但实际上它还是占位的，所以当你点击输入框上方空白处时，仍会唤起软键盘，就和我们之前所想的点击输入框之外区域就收起软键盘冲突了。
因此将input自身的点击获取focus禁止掉，就OK了。
之前都是自己乱七八槽的瞎记，第一次写给别人看，经验不足，时间仓促。不足之处，还望指正。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、网站建设 、平面设计服务。
如果您想订阅本博客内容，每天自动发到您的邮箱中， 请点这里
Fucking Young(简称 FY) 是一家专注于男性半球的年轻美学，我们自由使用和支配模特及艺术家合作，从而帮助自己与合作方达到合理的业务需求，建立一个拥有创造力的社区，赞助和发布这些惊艳的作品在我们的官网甚至手机产品上。带来的作品有FY品牌官网与移动端设计，展示部分界面与交互动效，Gif输出存在色差，实际情况以高保真视觉界面为准。
文章来源：UI中国
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务。
随着时间的发展，现在基本上人手一部手机的低头族。做为前端开发的程序猿，在开发移动端web应用的时候，对面一堆各色尺寸不一样的屏幕，就有点淡淡的忧伤。
以上是2018年二月份的友盟数据，可在这里查看详情
很明显我们所要实现的就是在上述如此之多的屏幕,都能实现UI大大出的视觉图上的效果。而要实现这样的效果主要有两个难点
各屏幕适配各屏幕的适配，有两种方案，flexible + rem 与 vw。这三个单词是什么意思，看着很眼熟，但是这两个方案居然是什么呢,请允许我细细道来。
flexible + rem显而易见,该方案是由rem 以及 flexible组成的。rem （font size of the root element）相对于根元素(即html元素)font-size计算值的倍数,flexible 即 flexible.js, 手淘团队提供的一个为该方案屏幕适配而写的一个库,主要实现的功能就是，根据屏幕的宽度给 html 元素设置一个合适的 font-size 值。
怎么样看的不是很懂是吧。让我来用一个页面场景再复述一遍。
正常情况下，我们的UI大大会以iphone6的尺寸为标准，做一套视觉效果图，并在上面进行标注，给到我们的标注图，如下所示
拿到这个图 我们该如何下手呢
到这里为止是不是就结束了呢 ? 很遗憾的告诉你并不是。为什么 html 元素的 font-size 要设置为 37.5px呢？现在这个界面在iphone6上能完美显示了，在iphone5s,iphone6p能完美显示吗？（iphone6, iphone6s, iphone7. iphone8屏幕没有发生变化，本文直接用iphone6代替了。）上面的两个问题 我们还有没解决，这个时候就轮到flexible登场了。只需要像如下引入就可实现用js来自动根据屏幕宽度设置 html元素的font-size的值。
<script src="http://g.tbcdn.cn/mtb/lib-flexible/0.3.4/??flexible_css.js,flexible.js"></script>引申一下在上述过程中，你会发现，UI给到我们的一般是px标注的图，我们将其转化为rem，这个过程其实会花费很大的计算时间。做为一个合格的程序员，我们应该把这种机械性无脑的操作交给计算机来实现。我使用的是PostCss的插件 postcss-px2rem,这个插件能让我们在写代码时候直接写px，在构建的时候自动将我们所写的px转换为rem，大大提升了我们的开发效率。
vw这个vw的方案，相当而言还比较新。vw 即（viewport width）可视窗口的宽度。之所以把这个方案放在后面来说，是因为viewport在去年（2017年）的时候存在不少的兼容性问题，各个浏览器的支持并不是很好。但是来到了2018年这个时间点，viewport单位意见得到了众多浏览器的支持（80.45%）。
可以在这里查看。
接下来就让我们来正式了解下这个方案吧。vw既然是一个尺寸单位，那它的宽度等于多少呢？等于1%整个屏幕的宽度。举个例子，再次以iphone6手机为例，100vw = 750px => 1vw = 7.5px
再一次那上次的界面做示范
到这里为止是不是就结束了呢? 是的就是这么简单。
引申一下跟之前一样的痛点，我们仍然需要花费大量不必要的计算时间去把标注图中的px转换为vw，有没有类似于postcss-px2rem的工具呢？很荣幸能再次站在巨人的肩膀上，已经有大神写了了类似的PostCss插件 postcss-px-to-viewport
1px问题移动端的屏幕不仅仅分辨率有差异，其实还有Retina屏的问题。正常情况下，我们代码里的1px在屏幕上就应该显示一个像素点，但是在Retina屏下则不仅仅是一个像素点。再次拿iphone6为例，其dpr(device pixel ratio)设备像素比为2，css中一个1x1的点，其实在iphone6上是2x2的点,并且1px的边框在devicePixelRatio = 2的Retina屏下会显示成2px，在iPhone6 Plus下甚至会显示成3px。
这样的话，我们就会发现在有些手机上1px明显跟另外的一些手机的1px粗细不一样。其实大多数的小公司不会扣这样的一个细节，比如说我们公司不会。(^__^) 嘻嘻……
但是作为一个有追求的前端工程师，我们应该尽量的把事情做的完美一点，（ps.像大公司看齐，在大公司这个细节问题其实是不容忽视的，为了自己以后的发展前途，我们有必要把这个细节完善掉的。）
这个问题的解决方案有很多，个人觉得最简单方面的还是大漠大大的一种解决方案。使用postcss-write-svg插件,
@svg 1px-border { height: 2px; @rect { fill: var(--color, black); width: 100%; height: 50%; } }.example { border: 1px solid transparent; border-image: svg(1px-border param(--color #00b1ff)) 2 2 stretch;}编译出来就是
.example { border: 1px solid transparent; border-image: url("data:image/svg+xml;charset=utf-8,%3Csvg xmlns='http://www.w3.org/2000/svg' height='2px'%3E%3Crect fill='%2300b1ff' width='100%25' height='50%25'/%3E%3C/svg%3E") 2 2 stretch;}其他小程序中的屏幕适配最近在写小程序，在小程序里，使用的是小程序的那套，跟平时用的vue全家桶以及react全家桶不一样，并没有配置webpack，在这种情况下我们使用postcss其实很困难（反正我是搞不出来/(ㄒoㄒ)/~~）
那该怎么办呢，小程序提供了一个自己的单位, rpx（responsive pixel）: 可以根据屏幕宽度进行自适应。规定屏幕宽为750rpx。如在 iPhone6 上，屏幕宽度为375px，共有750个物理像素，则750rpx = 375px = 750物理像素，1rpx = 0.5px = 1物理像素。
设备
iPhone5
iPhone6
iPhone6p
我们直接用拿到iphone6的标注图，直接写rpx就好。
移动端推广速度快，效果好，越来越多的企业，商家开始重视移动站的建设和移动页面（h5）的制作。随着移动页面的玩法越来越多，对前端技术的要求也会越来越高。
关于移动设备一些基本概念的理解。
网站示例
网址：https://github.com/amfe/lib-flexible；
一个完整的App包含很多页面，设计一个App是一个很系统的工程。竹子会陆续撰写教程，带着大家完整的学习设计App的过程。我们先从登录页设计开始学习。
justinlam：“我总觉得页面不太好看但是我又说不出来”，“我不懂设计，但是我就是觉得不协调”，“你觉得这好看？你的审美要加强啊”这些听着熟悉的话往往是产品和设计产生矛盾的开端。还有一种评价叫说不出哪里好也说不出哪里不好，相信很多人也有过感同身受的无奈。
蓝蓝设计的小编 http://www.lanlanwork.com