0%

年终总结-前端易用性规范

从今年7月份开始,因为公司需要,亟需解决产品易用性痛点问题,我开始前端易用性改进工作,我总结了易用性的6个方面,梳理出24个改进点,在随后的版本中逐步落地,目前大部分改进点都得到落实,产品的易用性得到极大的改观,几个月的辛勤付出终有成果,心中甚是欣慰。与此同时,我也负责前端的设计开发以及前端负责人工作,还好自己的基本功扎实😊,虽然一直从事后端研发,极短的时间内,我已经可以娴熟的进行前端开发和解决各种疑难问题,而团队管理更是我擅长的,团队有成员对我说,你要是早点来就好了,我就可以学到更多东西,这真是对我最大的褒奖。短短几个月的时间,我已经把前端的代码翻了一遍,说实在,以前代码的规范性非常差,组件复用性更差,完全没有复用的思想,整个团队要提升的地方实在太多了。在开发过程中,我发现很多问题经常重复出现,例如残留数据的问题,一方面是状态管理使用不当,全部都是用的全局状态,另一方面是没有重置状态的意识。因此我将近几个月的经验总结成一份规范,不仅能够提升易用性而且可以避免很多前端Bug,也算是一份年终总结,希望对大家有所启发和帮助。

一.前言

一个易用的界面会给人带来舒适的体验,同时也能够吸引用户,拉近用户与产品之间的距离,从而创造市场价值。易用性包含如下6个方面:

img

  • 可操作性:用户在这个界面中有很强控制力;
  • 错误处理:用户很少会造成错误,他们从错误中走出很快;
  • 效率:用户完成一个任务很快;
  • 吸引力:这个界面很吸引人,让用户享受使用的过程;
  • 可理解性:用户很容易理解他所看到的,对于一个新用户来说,学习如何在界面中操作很简单;
  • 规范性:界面依从规范、标准。

本规范围绕上述目标,从两个方面规范和指导设计开发过程,从而保证产品的易用性,第一方面是组件规范,主要解决吸引力和规范性问题,使得产品具有美观和一致的界面风格;第二方面是设计规范,主要解决可操作性、错误处理、效率、可理解性和规范性方面的问题,总结了最佳的交互设计实践,提升易用性的同时也能够避免很多前端Bug。

本规范主要面向UCD设计师和前端开发工程师,在进行原型设计和前端设计开发时需要严格遵循本规范。

二.组件规范

每一个产品有自己的界面风格,这种风格主要体现在组件的视觉表现上,是一种产品显著区别于另一个产品的主要因素。当一种风格确定下来之后,需要通过组件规范形成统一的约束,使得产品风格能够保持一致。

组件规范以平面设计稿的方式呈现,详见[SVN](https://cloudsvn.fiberhome.com/develop_team/04 Portal组/08\ 质量提升/前端设计规范/组件规范/FitOS_新规范.zip),主要涵盖如下几个方面:

1.布局和导航

  • 页面结构

  • 菜单

    1. 主菜单最多二级,位置侧边栏或顶部,一级菜单有图标
    2. 面包屑,菜单帮助
  • 页面

    1. 三级页签导航(可选)
    2. 列表页或概览页
    3. 详情页(可选)
  • 全局header

2.图标

  • 格式:svg,线框风格,单色(随主题色变化)
  • 大小:
  • 交互效果:hover,选中

3.颜色

  • 主题色
  • 辅助色
  • 中性色
  • 功能色
  • 特殊色

4.字体字号

  • 字体
  • 字号
  • 加粗
  • 行高

5.组件

  • 表格
  • 按钮
  • 页签
  • 对话框
  • 向导
  • 表单

三.设计规范

设计规范主要从交互设计和开发实现的角度,总结最佳设计实践,提升用户的使用体验。设计规范分强制和建议级别,强制级别必须遵守,包括已有功能和新功能,建议级别可自行决定是否采用,但是一旦采用则必须所有功能保持一致。

1.路由

  1. 【强制】二级菜单,三级页签,详情页均有独立的URL,URL不能携带query参数。

  2. 【强制】详情页通过URL直接访问,不能从列表获取任何数据。

  3. 【强制】详情页的URL一般格式是:{列表页URL}/{id},存在一些特殊情况,如有一些没有存库的资源,底层openstack详情接口需要同时传id和name,这时详情页的URL格式为:{列表页URL}/{id}/{name},如遇其他特殊情况需要更新规范,列举在此。

  4. 【强制】凡是有详情页的,操作日志中需要能够支持跳转,删除操作除外,其他页面是否做跳转的原则:

    • 跳转确实对用户有帮助,能够通过跳转后的详情页查看有用的信息。
    • 如果某种资源做过跳转,那么所有页面保持一致,例如私网的VPC做了跳转,那么其他页面的VPC也都做跳转。
    • 跳转通过名字跳转,没有名字则使用id。
  5. 【强制】点击一级菜单,展开二级菜单;点击二级菜单,显示对应列表页或者自动切换到三级页签的第一个页签;三级页签切换页签,展示相应列表页,URL也随之切换。

  6. 【强制】进入二级菜单后,二级菜单保持高亮。

  7. 【强制】列表页通过名字列链接跳转到详情页,没有名字则通过id列,如果列表已经包含了详情的所有信息,则可以不实现详情页。

  8. 【建议】详情页可以通过面包屑进行切换,不需要返回列表页再切换。

2.操控

  1. 【建议】列表页和详情页都可以发起操作。
  2. 【建议】表格提供批量操作入口。
  3. 【强制】点击等事件不要进行传播,例如点击tooltip,不要传播到tooltip后面的组件。
  4. 【强制】操作流程中不能出现跳转到其他页面而中断当前流程,应该采用弹出对话框方式,保证当前操作流程能够继续。
  5. 【强制】全局header固定在顶部,滚动时总是固定在顶部。
  6. 【强制】需要控制tooltip显示的位置,不要遮盖按钮等用户交互元素。
  7. 【建议】当更多操作超过10个时,需对操作进行分组并横向排列,每列最多显示10个操作。
  8. 【建议】列表行操作,当操作小于等于4个时,全部固定显示,超过4个时,固定编辑,删除,其他放入更多。
  9. 【强制】不支持的操作不显示,对于固定显示的操作则置灰。
  10. 【建议】能够一页完成的就不要使用向导分多步完成。
  11. 【建议】新建父对象后直接跳转到详情页新建子对象。
  12. 【强制】下拉框当页面滚动时不能和选择器分离,而是虽则选择器滚动而滚动。
  13. 【建议】umi的loading是接口粒度,列表某行的操作未返回会阻塞其他行操作,此时需要自己实现行粒度的loading。
  14. 【强制】对话框完成时,操作失败则对话框不关闭,成功则关闭。
  15. 【强制】列表支持点击行任意位置选中,此时单元格事件优先级更高,如果响应单元格事件,则不再选中行,符合规则3。
  16. 【强制】列表不可选择的行置灰。

3.输入

  1. 【建议】对于不太重要的字段提供默认值,如子网名称,作用不太大,可使用默认值。
  2. 【强制】对于可枚举数据,不要使用输入框,选项小于等于3项时,使用平铺的单选控件,大于3项时使用下拉选择控件。
  3. 【建议】IP段的输入根据掩码简化地址的输入。
  4. 【建议】IP地址池的输入要将复杂的语法转换为用户的交互输入,语法不直接暴露给用户。
  5. 【强制】下拉选择内容多于10项时提供搜索。
  6. 【强制】搜索输入框提供清除按钮。
  7. 【建议】在适当的地方提供拖拽功能:例如上传文件选择。
  8. 【建议】有明确范围的数值输入使用数字输入组件,输入超过最大值时自动变为最大值,输入小于最小值时自动变为最小值。
  9. 【强制】下拉选择内容显示不完整时需要tooltip。

4.提示与反馈

  1. 【强制】所有用户输入,前端需要对长度、范围、格式进行本地校验,校验通过才能下发后台。
  2. 【强制】操作置灰提示方式是右侧放置问号图标,问号图标上tooltip给出提示。
  3. 【强制】按钮置灰提示方式是直接tooltip给出提示。
  4. 【强制】输入控件的提示放在控件下方,不要通过在label旁的问号图标给出提示。
  5. 【强制】输入错误提示通过冒泡方式实时提示。
  6. 【强制】用户触发页面加载时,页面和按钮需要loading效果,定时刷新时不要loading。
  7. 【强制】按钮不能操作时置灰不可用。
  8. 【建议】编辑操作,用户没有改变数据时,不可下发后台。
  9. 【强制】后端请求返回提示使用通知组件,浏览器右侧弹出,成功则停留5秒自动关闭,失败不自动关闭,用户可手动关闭。详情默认收起,如果失败,则自动展开详情。
  10. 【建议】异步操作请求提示不自动关闭,当操作真正完成时后端推送消息给前端,此时在原来的消息提示中给出最终结果,后续同上。
  11. 【强制】全局消息提示使用消息组件,要么嵌入页面中,用户可关闭。要么浏览器上方弹出,停留4秒自动关闭,用户不可手动关闭。最多显示1个全局弹出消息。
  12. 【强制】危险操作给出确认提示,用户确认之后才下发后台。
  13. 【强制】必填字段在label的左侧必须有红色的*。
  14. 【建议】文本输入框要有灰色占位符,提示用户需要输入什么内容。
  15. 【强制】没有数据时,需要有空状态文字和图标提示。

5.数据管理

  1. 【强制】所有页面需要提供手工刷新,有状态变化的页面需要支持自动刷新。
  2. 【强制】使用定时器时需要非常小心,避免出现僵尸定时器,这通常是由于打开定时器和清除定时器没有配对,重复打开了定时器,这样前一个定时器就永远关闭不了,好的习惯是在打开定时器之前总是先清除一下。
  3. 【强制】对话框关闭或完成后,需要清除上一次数据,避免再次打开对话框出现数据残留,特别的antd form的数据需要resetFields或setFieldsValue清除。清除数据前先隐藏对话框,避免对话框出现闪变。
  4. 【强制】离开页面(包括通过浏览器回退),需要清除页面状态,避免再次回到页面出现残留,如对话框自动出现。
  5. 【强制】只有状态需要在多个组件共享时才放到redux中,否则状态保存在组件中。这样可以避免切换页面后会先显示上次的数据问题,也可以避免一些数据残留问题。
  6. 【强制】向导页面中已填数据,在上下步切换时需要保留。
  7. 【建议】必须进行数据选择的选择列表,只有一项数据时,默认选中。
  8. 【强制】字段为null时显示–,空字符串还是显示实际值。
  9. 【强制】避免字段出现重叠或超出边框,要让字段自动换行或省略显示。
  10. 【强制】字段过长时省略显示,备注最长32,其他最长16,超过长度则截取最大长度后追加…显示,中文一个字长度按1算。
  11. 【强制】列表数据过多时需要使用分页,支持分页、跳页、设定每页条数。
  12. 【强制】表格支持宽度随屏幕自适应,不出现横向滚动条。但是缩放宽度过小,无法显示所有列时,需要横向滚动条。
  13. 【建议】对话框支持拖动和最大化。
  14. 【建议】不常用选填内容放入[高级选项],默认收起。
  15. 【强制】列表中枚举字段需要支持过滤(依赖openstack底层过滤需要视底层是否支持而定,如底层不支持则无法实现过滤)。
  16. 【强制】列表中名称,时间字段需要支持排序,其他字段视需求而定(同样依赖底层的视底层能力而定)。
  17. 【强制】所有资源都需要创建和更新时间字段。
  18. 【强制】列表字段支持自定义显示的列,某些列可固定显示,不允许隐藏。
  19. 【强制】列表支持字段模糊检索(同样依赖底层的视底层能力而定)。
  20. 【建议】复杂的列表需要支持组合条件检索,并能够保存查询条件,以便重复使用。
  21. 【建议】列表支持字段为空的检索。

6.一致性

  1. 【强制】中文环境,标点统一用中文标点。
  2. 【强制】中文环境,除了常用的英文缩写,如CPU,英文都应该翻译为中文。
  3. 【强制】错误提示统一不加感叹号。
  4. 【强制】专业术语在不同地方保持一致性。
  5. 【强制】所有页面符合组件规范。
  6. 【强制】所有页面需要适配各种主题,在各主题下显示正常,包括亮色,暗色和暗黑主题。

7.兼容性

  1. 【强制】浏览器至少支持chrome 85及以上和firefox 79及以上。
  2. 【强制】最小分辨率1366*768,保证此分辨率及以上的显示正常。
-------------本文结束感谢您的阅读-------------