列表、库和其他应用程序？

原文发布于 2012 年 10 月 27 日（星期六）

如果您习惯了早期版本的 SharePoint，您可能已注意到，这些版本中的 UI 对列表、文档库、图片库、讨论列表和调查等内容进行了区分。此区分基于技术上的差异而不是可能与用户相关的任何内容，同时这会造成大量的混乱情况。例如，为何当调查和图片库仅包含一种类型的项时将拥有自己的类别，而列表类别可包含几十个选项？哪个项目始终会将日历视为列表？

 

图 1：SharePoint 2010 网站中显示不同的列表和库的分类的左侧导航区域的示例。

 

在我们考虑如何解决网站上的异常分类功能问题时，发生了另一件有趣的事情：“应用程序”概念变成了主流。人们在使用其手机和网站（如 Facebook）上的应用程序时感到得心应手。似乎每天都会出现用于安装应用程序的新位置。我们希望用户能够更轻松地将新功能用于 SharePoint 网站中，而无需了解有关代码的部署方式和位置的任何信息。

我们考虑将“应用程序”作为另一种类别（如列表/库/等）附加，但这似乎有点荒谬。我们询问了客户如何看待其网站以及网站包含的内容，并反复收到以下信息：

• 网站本身是一个场所。
• 用户是访问该场所的人员。
• 主题是可更改该场所的外观的项目。
• 其列表/库/等中的其他功能与您在手机上可找到的“应用程序”类似。

如果我们从这个方面进行考虑，则将任何内容称作应用程序会变得很有意义。对于列表/库和此称作“应用程序”的新项目而言，与现有项目进行交互、查找并获取新的项目以及丢弃不再相关的项目的流程是相同的。我们决定基于术语“应用程序”整个所有内容，而不是引入第六种类别“向我的网站添加新功能但出现某个技术方面的原因不同于其他五种类别的项目”。调查和图片库与来自 Contoso 的第三方应用程序之间存在技术上的差异。但从体验的角度来看，它们全都是应用程序。

图 2：SharePoint 2013 的网站中显示列表、库和其他应用程序的一个新类别的“网站内容”页的示例

在我们用于列出五种像应用程序的项目的网站的“网站内容”页上，标头现在显示列表、库和其他应用程序。通过调用列表和库，我们希望弥补难以理解的旧技术分类与新的所有内容都为应用程序模型之间的差距。我们对目前收到的回应感到十分高兴，期待您提供有关您在网站中如何使用应用程序的更多反馈。请通过发表您的评论来告知我们这些信息！

 

 

这是一篇本地化的博客文章。请访问 Lists, Libraries, and other Apps? 以查看原文