微信小程序怎么设计

新手学堂018

微信小程序怎么设计,第1张

基于微信小程序轻快的特点,我们拟定了小程序界面设计指南和建议。设计指南建立在充分尊重用户知情权与操作权的基础之上。旨在微信生态体系内,建立友好、高效、一致的用户体验,同时最大程度适应和支持不同需求,实现用户与小程序服务方的共赢。

为了避免用户在微信中使用小程序服务时,注意力被周围复杂环境干扰,小程序在设计时应该注意减少无关的设计元素对用户目标的干扰,礼貌地向用户展示程序提供的服务,友好地引导用户进行操作。

每个页面都应有明确的重点,以便于用户每进入一个新页面的时候都能快速地理解页面内容。在确定了重点的前提下,应尽量避免页面上出现其它与用户的决策和操作无关的干扰因素。

此页面的主题是查询,却添加了诸多与查询不相关的业务入口,与用户的目标无关,易造成用户的迷失。

去掉任何与用户目标不相关的内容,明确页面主题,在技术和页面控件允许的前提下提供有助于用户决策和操作的帮助内容,比如最近搜索词等。

操作没有主次,让用户无从选择。

首先要避免并列过多操作让用户选择,在不得不并列多个操作时,需区分操作主次,减轻用户的选择难度。

为了让用户顺畅地使用页面,在用户进行某一个操作流程时,应避免出现用户目标流程之外的内容而打断用户。

用户本打算进行搜索,在进入页面时却被突如其来的模态抽奖框所打断;对于抽奖没有兴趣的用户是非常不友好的干扰;而即便有部分用户确实被“诱人”的抽奖活动所吸引,离开主流程去抽奖之后可能就遗忘了原本的目标,进而失去了对产品真正价值的利用和认识。

一旦用户进入我们的小程序页面,我们就有责任和义务清晰明确地告知用户身在何处、又可以往何处去,确保用户在页面中游刃有余地穿梭而不迷路,这样才能为用户提供安全且愉悦的使用体验。

导航明确,来去自如

导航是确保用户在网页中浏览跳转时不迷路的最关键因素。导航需要告诉用户,当前在哪,可以去哪,如何回去等问题。首先在微信系统内的所有小程序的全部页面,均会自带有微信提供的导航栏,统一解决当前在哪,如何回去的问题。在微信层级导航保持体验一致,有助于用户在微信内形成统一的体验和交互认知,无需在各小程序和其他微信页面的切换中新增学习成本或改变使用习惯。

微信导航栏

微信导航栏,直接继承于客户端,除导航栏颜色之外,开发者无需亦不可对其中的内容进行自定义。但开发者需要规定小程序各个页面的跳转关系,让导航系统能够以合理的方式工作。

微信导航栏分为导航区域、标题区域以及操作区域。其中导航区控制程序页面进程。目前导航栏分深浅两种基本配色。

导航区(iOS)

微信进入小程序的第一个页面,导航区通常只有一个操作——“返回”,即返回进入小程序前的微信页面。进入小程序后的次级页面,导航区的操作为——“返回”和“关闭”。“返回”,即返回上一级小程序界面或微信界面。“关闭”,即在当前界面直接退出小程序,回到进入小程序前的微信页面。

导航区(Android)

导航区仅存在唯一操作——直接退出小程序,回到进入小程序前的微信或系统桌面,安卓手机自带的硬件返回键执行返回上一级页面的操作。

安卓导航存在一类特殊情况:当用户通过操作区的菜单将小程序添加至安卓桌面,并从安卓桌面打开小程序时,小程序的首页,不展示导航按钮。仅展示小程序标题和操作区。小程序次级页面,导航区只有返回上一级页面的操作,而点击安卓手机自带的硬件返回键也起到相同作用。

微信导航栏自定义颜色规则(iOS和Android)

小程序导航栏支持基本的背景颜色自定义功能,选择的颜色需要在满足可用性前提下,和谐搭配微信提供的两套主导航栏图标。建议参考以下选色效果:

选色方案示例

页面内导航

开发者可根据自身功能设计需要在页面内添加自有导航。并保持不同页面间导航一致。但是受限于手机屏幕尺寸的限制,小程序页面的导航应尽量简单,若仅为一般线性浏览的页面建议仅使用微信导航栏即可。

开发者可选择小程序页面添加标签分页(Tab)导航。标签分页栏可固定在页面顶部或者底部,便于用户在不同的分页间做切换。标签数量不得少于2个,最多不得超过5个,为确保点击区域,建议标签数量不超过4项。一个页面也不应出现一组以上的标签分页栏。

其中小程序首页可选择微信提供的原生底部标签分页样式,该样式仅供小程序首页使用。开发时可自定义图标样式、标签文案以及文案颜色等,具体设置项如图标尺寸等参考可参考开发文档和WeUI基础控件库。

顶部标签分页栏颜色可自定义。在自定义颜色选择中,务必注意保持分页栏标签的可用性、可视性和可操作性。

减少等待,反馈及时

页面的过长时间的等待会引起用户的不良情绪,使用微信小程序项目提供的技术已能很大程度缩短等待时间。即便如此,当不可避免的出现了加载和等待的时候,需要予以及时的反馈以舒缓用户等待的不良情绪。

启动页加载

小程序启动页是小程序在微信内一定程度上展现品牌特征的页面之一。本页面将突出展示小程序品牌特征和加载状态。启动页除品牌标志(Logo)展示外,页面上的其他所有元素如加载进度指示,均由微信统一提供且不能更改,无需开发者开发。

页面下拉刷新加载

在微信小程序内,微信提供标准的页面下拉刷新加载能力和样式,开发者无需自行开发。

微信下拉刷新错误使用案例

请避免以下错误使用情况,确保信息的可见性和页面的可用性。

页面内加载反馈

开发者可在小程序里自定义页面内容的加载样式。建议不管是使用在局部还是全局加载,自定义加载样式都应该尽可能简洁,并使用简单动画告知用户加载过程。开发者也可以使用微信提供的,统一的页面加载样式,如图中例所示。

模态的加载样式将覆盖整个页面的,由于无法明确告知具体加载的位置或内容将可能引起用户的焦虑感,因此应谨慎使用。除了在某些全局性操作下不要使用模态的加载。

局部加载反馈

局部加载反馈即只在触发加载的页面局部进行反馈,这样的反馈机制更加有针对性,页面跳动小,是微信推荐的反馈方式。例如:

加载反馈注意事项

若载入时间较长,应提供取消操作,并使用进度条显示载入的进度。

载入过程中,应保持动画效果;无动画效果的加载很容易让人产生该界面已经卡死的错觉。

不要在同一个页面同时使用超过1个加载动画。

除了在用户等待的过程中需予以及时反馈外,对操作的结果也需要予以明确反馈。根据实际情况,可选择不同的结果反馈样式。对于页面局部的操作,可在操作区域予以直接反馈,对于页面级操作结果,可使用弹出式提示(Toast)、模态对话框或结果页面展示。

页面局部操作结果反馈

对于页面局部的操作,可在操作区域予以直接反馈,例如点击多选控件前后。对于常用控件,微信设计中心将提供控件库,其中的控件都已提供完整操作反馈。

页面全局操作结果——弹出式提示(Toast)

弹出式提示(Toast)适用于轻量级的成功提示,15秒后自动消失,并不打断流程,对用户影响较小,适用于不需要强调的操作提醒,例如成功提示。特别注意该形式不适用于错误提示,因为错误提示需明确告知用户,因而不适合使用一闪而过的弹出式提示。

页面全局操作结果——模态对话框

对于需要用户明确知晓的操作结果状态可通过模态对话框来提示,并可附带下一步操作指引。

页面全局操作结果—结果页

对于操作结果已经是当前流程的终结的情况,可使用操作结果页来反馈。这种方式最为强烈和明确的告知用户操作已经完成,并可根据实际情况给出下一步操作的指引。

异常可控,有路可退

在设计任何的任务和流程时,异常状态和流程往往容易被忽略,而这些异常场景往往是用户最为沮丧和需要帮助的时候,因此需要格外注意异常状态的设计,在出现异常时予以用户必要的状态提示,并告知解决方案,使其有路可退。

要杜绝异常状态下,用户莫名其妙又无处可去,停滞在某一个页面的情况。上文中所提到的模态对话框和结果页面都可作为异常状态的提醒方式。除此之外,在表单页面中尤其是表单项较多的页面中,还应明确指出出错项目,以便用户修改。

异常状态——表单出错

表单报错,在表单顶部告知错误原因,并标识出错误字段提示用户修改。

从PC时代的物理键盘鼠标到移动端时代手指,虽然输入设备极大精简,但是手指操作的准确性却大大不如键盘鼠标精确。为了适应这个变化,需要开发者在设计过程中充分利用手机特性,让用户便捷优雅的操控界面。

由于手机键盘区域小且密集,输入困难的同时还易引起输入错误,因此在设计小程序页面时因尽量减少用户输入,利用现有接口或其他一些易于操作的选择控件来改善用户输入的体验。

例中,在添加银行卡时,采用摄像头识别接口来帮助用户输入。除此之外微信团队还对外开放例如地理位置接口等多种微信小程序接口,充分利用这些接口将大大提高用户输入的效率和准确性,进而优化体验。

除了利用接口外,在不得不让用户进行手动输入时,应尽量让用户做选择而不是键盘输入。一方面,回忆易于记忆,让用户在有限的选项中做选择通常来说是容易于完全靠记忆输入;另一方面,仍然是考虑到手机键盘密集的单键输入极易造成输入错误。例如图中,在用户搜索时提供搜索历史快捷选项将帮助用户快速进行搜索,而减少或避免不必要是键盘输入。

避免误操作

因为在手机上我们通过手指触摸屏幕来操控界面,手指的点击精确度远不如鼠标,因此在设计页面上需点击的控件时,需要充分考虑到其热区面积,避免由于可点击区域过小或过于密集而造成误操作。当简单的将原本在电脑屏幕上使用的界面不做任何适配直接移植到手机上时,往往就容易出现这样的问题。由于手机屏幕分辨率各不相同,因此最适宜点击像素尺寸也不完全一致,但换算成物理尺寸后大致是在7mm-9mm之间。在微信提供的标准组件库中,各种控件元素均已考虑到了页面点击效果以及不同屏幕的适配,因此再次推荐使用或模仿标准控件尺寸进行设计。

利用接口提升性能

微信设计中心已推出了一套网页标准控件库,包括sketch设计控件库和Photoshop设计控件库,后续还将完善小程序组件,这些控件都已充分考虑了移动端页面的特点,能够保证其在移动端页面上的可用性和操作性能;同时微信开发团队也在不断完善和扩充微信小程序接口,并提供微信公共库,利用这些资源不但能够为用户提供更加快捷的服务,而且对页面性能的提高有极大作用,无形之中提升了用户体验。

除了以上所提到的种种原则,建议接入微信的小程序还应该时刻注意不同页面间的统一性和延续性,在不同的页面尽量使用一致的控件和交互方式。

统一的页面体验和有延续性的界面元素都将帮助用最少的学习成本达成使用目标,减轻页面跳动所造成的不适感。正因如此,小程序可根据需要使用微信提供的标准控件,以达到统一稳定的目的。

微信内字体的使用与所运行的系统字体保持一致,常用字号为20,18,17,16,1413,11(pt),使用场景具体如下:

主内容Black黑色,次要内容Grey灰色;时间戳与表单缺省值Light灰色;大段的说明内容而且属于主要内容用Semi黑。

蓝色为链接用色,绿色为完成字样色,红色为出错用色Press与Disable状态分别降低透明度为20%与10%。

解决微信小程序怎样设置textarea文本域输入的步骤如下:

1第一步,打开微信小程序开发工具,在指定的wxml文件中插入一个textarea组件,设置最大长度、失去焦点事件等。

2第二步,在界面对应的JavaScript文件,添加失去焦点事件,并获取文本域文字内容。

3第三步,接着保存代码并在模拟器中预览界面显示效果,可以看到一个文本域。

4第四步,在文本域组件中输入相应的文字内容,尽可能输入多的内容。

5第五步,接着在浏览器的控制台下方,查看打印的结果值,跟文本域中的一致。

6第六步,最后再输入其他的文字内容,由于限制了文本域的最大输入长度,边输入边查看结果。这样就解决了微信小程序怎样设置textarea文本域输入的问题了。

我从前端的视角,为大家分析下微信小程序和HTML5之间的主要区别

第一条是运行环境的不同。

传统的HTML5的运行环境是浏览器,包括webview,而微信小程序的运行环境并非完整的浏览器,大家注意,我这里写的是“非完整的浏览器”,有以下几个原因

小程序的开发过程中会用到HTML5相关的技术(并非全部)

小程序最后的发布上线需要微信审核,微信在不更新自身软件的情况下可以将小程序更新到自身软件内,这就联想到了ReactNative框架,并且已经有开发者在微信小程序的开发工具源码中发现使用了React和NodeWebkit库

官方文档中着重强调了脚本内是无法使用浏览器中常用的window对象和document对象(基于这一点,像zepto/jquery这种操作dom的库就被完全抛弃了)

所以我个人认为,小程序的运行环境很有可能是微信开发团队基于浏览器内核完全重构的一个内置解析器,针对小程序专门做了优化,配合自己定义的开发语言标准,提升了小程序的性能。

不过由于微信给开发者提供了开发工具,而开发工具中也内置了编程、调试、开发环境、发布于一身,我们也不用再探讨它的最终运行环境了,只要按照官方文档进行开发就可以了。并且从微信团队给开发者提供开发工具这一举动,让我联想到了苹果给开发者提供的X-CODE开发工具,可以想象微信的“野心”可见一斑

第二条是开发成本的不同。

这里我提出了一个问题,当我们面对一个HTML5web开发需求时,我们需要考虑什么呢?抛去开发工具(vscode、sublimtext、Atom等)不谈,大到前端框架(Angular、react、vue、backbone等)、模块管理工具(Webpack、Browserify等)、任务管理工具(Grunt、Gulp等),小到UI库选择、接口调用工具(ajax、FetchApi等)、浏览器兼容性等都要我们一一考略,再不济用jqery插件写H5,也要在开发过程中去寻找合适的jquery插件来配合项目。尽管这些工具可定制化非常高,并且提高了开发者的开发效率,但我相信项目开发的配置工作已经消耗了不少精力,尽管大部分开发者都有自己的配置模板,但长久以来对于项目中使用的各种外部库的版本迭代、版本升级所产生的成本应该也不低。

而当我们面对一个微信小程序的开发需求时,我们需要考虑什么呢?微信团队提供了开发者工具,并且规范了开发标准,前端常见的HTML、CSS变成了微信自定义的WXML、WXSS,WXML中尽管全部是自定义标签,但官方文档中都有明确的使用介绍,相信上手应该是非常容易的;WXSS、JSON和JS文件中的写法稍有限制,但整体相差不多。在统一了这些标准之后,作为一个开发者,你会发现,自己只要专注写程序就可以了:

当需要调用后端接口时,调用发起请求API

当需要上传下载时,调用上传下载API

当需要数据缓存时,调用本地存储API

引入地图、使用罗盘、调用支付、调用扫码等等功能都可以直接使用

UI库方面,框架自然带有自家weui库加成

并且在使用这些API时,你不用再去顾虑浏览器兼容性,不用担心生产环境中出现不可预料的奇妙BUG,可见微信小程序的开发成本确实相比以往的web开发低很多。

第三条是获取系统级权限的不同。

微信小程序相对于HTML5web应用能获得更多的系统权限,比如网络通信状态、数据缓存能力等,这些系统级权限都可以和微信小程序无缝衔接,也就是官方宣称的拥有NativeApp的流畅性能,而这一点恰巧是HTML5web应用经常被诟病的地方,这也是HTML5的大多应用场景被定位在业务逻辑简单、功能单一的原因。

第四条便是应用在生产环境的运行流畅度。

这条无论对于用户还是开发者来说,都是最直观的感受。长久以来,当HTML5应用面对复杂的业务逻辑或者丰富的页面交互时,它的体验总是不尽人意,需要不断的对项目优化来提升用户体验。但是由于微信小程序运行环境独立,尽管同样用htmlcssjs去开发,但配合微信的解析器最终渲染出来的是原生组件的效果,自然体验上将会更进一步。

首先,下载微信小程序源码,用微信开发者工具打开,在不同的小程序设置页中,根据参考文档步骤配置appid、appsecret等,此配置十分重要,保证每个参数正确无误,同时配置后端服务器地址。

检查是否按照weui样式框架编写,非 weui 样式编写或者是布局表现明显有误的话,调整样式,正确的完成HTML布局。

检查从小程序端拉取数据时,后台服务器是否使用https或https协议拉取请求,如果没有,务必更新;

检查js文件中wxrequest()接口传参是否正确,常见错误应为小程序端未传入参数,或参数未正确赋值,同时,请求成功后,看看数据是否有返回。

对小程序代码进行整体检查,尤其是页面元素交互、函数调用链路的逻辑,确保小程序的正常运行;

最后,可以在微信开发者工具点击“上传”调试,看看是否能够正常运行和预览。

输入代码

<textarea class="weui-textarea" placeholder="请输入文本" style="height: 33em" />

就可以设置了。

微信小程序 textarea 不可行的原因和简易解决方案

微信小程序中textarea没有bindchange事件,所以无法在输入时给变量赋值。

虽然可以使用bindblur事件,但是绑定bindblur事件,如果再点击按钮,则先执行完按钮事件后,再去执行bindblur事件,所以在js文件取不到输入值。

解决方法:结合from表单,textarea文本框输入后,再去点击提交按钮,这时会先执行textarea事件(获取文本框输入内容),再去执行数据提交,这样问题就解决了。

2wxml文件代码

3js文件代码

这里以npm引入小程序官方拓展组件库 recycle-view 为例

特别重要1在小程序根目录内,初始化 npm (官方文档上是没写出这一步,这里做个补充)

2在小程序中执行命令安装 npm 包(这里使用了recycle-view):

3在微信开发者工具中的菜单栏:工具 --> 构建 npm (这里记得先安装 npm 包,即步骤2):

完成构建后可以在目录树里看到了miniprogram_npm以及里面的weui-miniprogram组件文件夹

小程序上传文件生成订单的步骤:

公司客户要求在订单中添加文件上传功能,就开始查阅资料之旅了,微信小程序扩展能力中有现成的文件上传组件uploader可以使用,而这个项目是在表单中添加上传功能,因此需要考虑一些代码逻辑。

首先,刚开始忽略了逻辑问题,直接在上传文件的时候通过接口提交到后台,接着遭到了质疑:“如果用户没提交表单,上传的就已经到后台了,有点不合逻辑吧”

然后,重新整理逻辑,先把临时缓存一下,提交表单的时候,拿到缓存数据,通过接口把提交到后台,再把表单数据提交到后台(两个接口是分开的,后台给的,就这样用呗)

uploader简介

uploader是微信小程序WeUI组件库中的一个上传的组件,可以在小程序开发文档中--扩展能力--表单组件中找到相关用法。

这是一个集合了选择、上传、预览、删除的完整组件,属性定义也比较全面,可以自定义上传个数,有上传成功提醒和失败提醒,点击预览功能等,基本可以涵盖文件上传的所有功能要求。

用起来也很方便,在json文件中加入以下引用(可在官方文档找到),然后在wxml文件中直接引入该组件就行,使用起来很方便

{

"usingComponents": {

"mp-uploader": "weui-miniprogram/uploader/uploader"

}

}

官方文档提供了简单的使用案例,如图所示。