Office Add-in 设计规范与最佳实践

做者：陈希章 发表于 2017年8月6日

引子

离上一篇Office Add-in的文章已通过去了一段时间，期间有去年Office 365 Asia Devday & Hackathon的二等奖得到者闫晓迪写了Office365开发系列——开发一个全功能的Word Add-In ,另外我也写了两篇有关人工智能方面的文章

1. 人工智能背景下的Office 365现状和发展趋势
2. Office 365 机器人（Bot）开发入门

我一直在思考怎么为你们讲解Office Add-in开发，一方面确实须要实例（因此咱们须要更多的闫晓迪站出来），另外一方面来讲，我以为从一开始就讲解一些设计规范和最佳实践可能对你们会有较大帮助。

固然，实际上我也没有很是丰富的Office Add-in开发经验，这方面还须要有时间和案例的积累。因此这一篇文章的主要内容都来自于官方的手册，我稍微作了一些整理，增长了少许我我的的建议。若是但愿查看英文的版本，请访问：https://dev.office.com/docs/add-ins/overview/add-in-development-best-practices。

第一个规范：提供清晰的价值

这个原则之因此放在最前面，是由于它要回答“你为何须要开发这个Office Add-in”的终极哲学性问题。

下面几个最佳实践是比较适合关注的

1. 在不增长中断的状况下，帮助用户更好地基于Office Add-in完成创做。
2. 为Offie 提供新的应用场景。
3. 为Offie 嵌入一些辅助服务。
4. 提升Office 的使用体验达到实现更好的生产力的目的。

我要补充的一两点个人理解：一个好的Office Add-in由于提供明确，而且尽可能独特的价值 —— 不要贪大求全，而是由于专一于作好一件事情。同时，用户不该该被要求离开他当前所在的Office 环境，就能完成一些有意思的工做，而且与他自己在Office里面作的工做无缝地融合在一块儿。这个让我想起在人工智能背景下的Office 365现状和发展趋势 中提到的Tap和Rsearcher这两项功能。

若是你但愿将你的Add-in发布到Office Store，还有两个文档可能对你有用

1. 在发布以前，经过 Office Store validation policies 以及 Office Add-in host and platform availability 来确保你想要提供的Add-in所须要知足的一些策略。
2. 经过了解Create effective Office Store listings的一些细节，提升你的Office Add-in在Office Store能更好地被查找到，甚至被推荐。

第二个规范：打造引人入胜的首次使用体验

你永远没法改变留给别人的第一印象。这句话一样适合于Office Add-in开发的领域。下面的一些最佳实践或许能让你的Office Add-in给人留下深入印象，而且愿意长期使用下去。

1. 在首页上面清晰地告诉（引导）用户如何使用这个Add-in，不要一上来就要求用户注册啦，登陆啦，好好想想你到底能为他们提供什么。
2. 若是你的Add-in须要绑定数据，尽量在建立时提供范例数据做为参考。
3. 提供试用版。做为SaaS服务的一个基本理念，就是用户能够经过试用了解你的产品，而且决定是否要购买订阅。而即使是有接受订阅的高级版本，也建议保留一个免费的（但依然包含了有限功能的）版本。
4. 若是须要用户注册，应该尽量简单，尽量预先填好一些基本信息，而且避免邮件验证。
5. 若是有可能，应在应用中实现单点登录的体验，尤为是对于现有Office 365用户而言，他们自己就是有身份的。
6. 在应用中应该尽可能避免弹出窗口，若是没法避免，则应该让用户决定是否启用该功能。

虽然写了这么多条，但我总结起来可能就是一条：KISS原则用在这里是恰如其分的 —— Keep it simple, stupid —— 若是你让用户思考，你就输了。

第三个规范：使用Add-in Command

使用Add-in Command是很是常见的作法，它能够用来在Office 应用程序中添加Ribbon按钮，也能够在快捷菜单中增长子菜单。点击这些按钮或者子菜单，能够直接执行一段代码（一般是Javascript函数），也能够打开任务面板（Task Pane）以进一步操做。典型的Add-in Command效果图以下所示：

考虑到对触摸操做的支持，应该尽可能减小对于快捷菜单的依赖。

下面还有一些具体的建议

1. 尽量将Add-in Command经过添加组的方式合并到现有的Ribbon Tab（例如Insert，Review等）里面去，固然前提是你的功能，正好跟这些Ribbon Tab的含义是匹配的。
2. 若是不匹配，则尽量放在Home这个Ribbon Tab，这样能够减小用户查找你的Add-in Command的难度。
3. 可是若是你的自定义Add-in Command有超过6个顶级Ribbon Button，那么就建议单首创建一个Ribbon Tab了。
4. 在命名上面，Ribbon组的名称应该尽量跟你的Add-in一致。若是有多个组，那么每一个组都应该有清晰的命名，让用户一眼就知道它的用途。
5. 不要添加多余的按钮。请考虑奥卡姆的简单有效原则——“如无必要，勿增实体”。

第四个规范：遵循界面设计原则

值得高兴的一件事情是，微软为开发人员专门提供了Office UI Fabric这一套UX 框架，你能够直接使用Fabric Core Style开展工做，它主要提供了CSS的支持（字体，图标，内置组件等），但也能够结合你熟悉的UI框架使用，例如React和AngularJS。

Office UI Fabric是一切界面问题的解药，与此同时下面还有一些能够参考的最佳实践

1. 确保你的Add-in的用户体验跟Office宿主程序一脉相承。

2. 如无必要，不要添加多余的元素。

3. 为1366*768的主流分辨率优化设计，尽可能避免滚动条。

4. 不要使用未经受权的图像（或其余素材）。

5. 使用简单明了的语言。

6. 不要在Add-in作广告。

7. 考虑不一样平台的适用性，包括鼠标、键盘和触摸体验。

   经过Context.touchEnabled 能够检测到当前是否运行在触摸的模式下。若是在触摸模式下，还有几条参考的建议

   • 请确保全部的界面元素都拥有合适的尺寸。
   • 不要依赖于右键菜单和鼠标悬停等机制进行工做。
   • 确保在横屏和竖屏的状况下都能正常工做。
   • 在真实的设备中进行测试（使用Sideloading技术）

8. 增长辅助访问功能。

第五个规范：将性能始终放在重要位置

之前咱们固然也讲性能，但现在Office Web Add-in的话，这个就显得尤其重要了，你的Add-in可能会被成千上万的人使用，性能可能成为你的制胜法宝，反过来也可能葬送你全部的努力。

除了一直要将性能放在重要位置，从思想上很重视它以外，下面也有一些具体的建议

1. 确保Add-in加载时间在主要的网络环境下的加载时间不该该超过500毫秒。
2. 确保用户交互操做的时间不超过1秒。
3. 若是是长时间操做，请提供进度提示。
4. 对于公共资源（图片，CSS文件，脚本等）请考虑使用CDN技术加速，而且尽量在一个位置（尽量利用缓存的好处）。
5. 参考网站设计的一些基本规范。这个能够参考我几年前写的优化网站设计的三十五条建议。