构建Bootstrap

摘要：为了更好得收纳当前的信息并且为其他工具腾出空间，我需要使用到下拉菜单。经过几次的讨论，我们下定决心重新排列顶栏，移除了一些链接，实现了不支持多层次的下拉菜单。继续这个例子，我们收到了大量的围绕下拉菜单，并且重新考虑支持多层次菜单。

----最近在看新鲜出炉Bootstrap4,翻到了以前的一篇老文章，讲述了Tweter工程师构建Bootrap的初衷和过程。
以下翻译自Bootstrap 创始人Mark Otto的博客 Building Twitter Bootstrap讲诉了Bootstrap的创建历程。

原文地址:http://alistapart.com/article/building-t...

一年半以前，一小部分Twitter的工程师准备着手开发一个用于团队内部管理和分析工具，在围绕这个工具早期开展的一些会议上，我们决定带着一个更高的目标去创建这样一个能够为Twitter任何一个员工使用的工具，甚至Twitter以为的人们。因此，我们打算建立一个系统能够帮助像我们这样的人在这个基础上创建新的项目，所以Bootstrap就这样构建出来了。

我和Jacob Thornton创建的Bootstrap前端工具被用来帮助设计师和开发者快速高效地搭建网上应用，我们的目标是创建一个精致的、文档规范的、由HTML、CSS、JavaScript构建的具备灵活组件库，人们能够利用这个库来构建自己的应用，或者在这个库的基础上进行创新。至今，Bootstrap已经扩展到了几十个组件，而且成为了Github上最受欢迎的项目，超过了13,000 的关注者以及2000个分支。

这里我将透露Bootstrap创建的原因、它是如何被创建的、以及它是如何演变为一个设计系统的。

Twitter公司内部早期的一些工具设计得不够精致和人性化，以至于无法快速地进行开发并且重复使用，几个团队的成员都认识到了这个问题，而且认为这是一个对现在和未来项目的发展极佳的解决时机，认识到这一点，我们通过早期的设计和合作形成了了一个大致的计划。
站在一个更高的角度来看，我们的计划大致是这样的：

这个工具（Bootstrap）的一部分开发者与产品经理以及潜在的用户一起工作，来确定关键的功能和特征。

我通过与开发者一起工作来确定需求，然后在浏览器中实现它，创建可视化语言和寻求互动。在实现第一步之后，我们仔细讨论了每一个组件和衡量了其他选项及实现方法，再开展下一步工作。

之后，我们开始朝着最初创建的这样一个新的内部工具来设计和编码，这段时间里，我们快速地执行、测试、迭代每个新特征。

最后，作为后续的工作，我把这个内部工具集中相同的组件抽出来，把他们添加到共享代码库中（Bootstrap），提炼并且提供文档，供其他项目使用。

这样的方式意味着沟通是构建Bootstrap的关键，大部分设计工作发生在编码，

最终我们把这个经验总结成：设计师与开发者配对。与开发者的持续沟通启发了Bootstrap，并且推动了Bootstrap一年后的持续发展。从构思理念到简易雏形的编码以及跨学科的合作，这些使得Bootstrap在TWitter公司内部成功地被使用。这个过程促进了Bootstrap的每一个特征的开发，随着时间的推移，效果显著。

这种方式构建Bootstrap意味着沟通是关键，大部分设计发生在编码中，当完成Bootstrap的可交付版本的时候，尽可能地交换大家的意见变得非常有意义。这使得鼓励开发简洁的组件深入到一个优秀开发者心里，但是视觉上的精良和期望是一个专业设计者的水准。

让我们看一看Bootstrap的一个例子：下拉菜单。为了更好得收纳当前的信息并且为其他工具腾出空间，我需要使用到下拉菜单。许多人都会在他们的应用中用到下拉菜单，每一个人都有不同的实现、交互和视觉设计。那么我们将会如何使用它呢？有了上面的提纲之后，下面这些特征将会体现在Bootstrap中：

我们意识到我们使用了太多了导航链接以及固定顶栏的动作，可伸缩的、多层次的下拉菜单看起来是一个解决方案。

我们通过合作来确认为什么需要这么多的链接和动作，以及为什么我们需要支持多层次。

经过几次的讨论，我们下定决心重新排列顶栏，移除了一些链接，实现了不支持多层次的下拉菜单。那个时候，这样做意味着需要额外的编码，并且实现起来很复杂，我们想要避免这些。

接下来，我们为下拉菜单的：hover写了基本的Html和Css代码，我们在代码库上优化了视觉上的一些细节，并且抽象出来、编写了文档，加入到Bootstrap中。

在最后一步抽象至Bootstrap时，我们在动作的触发上选择了点击而不是悬停，我们发现这有利于避免用户产生困惑和无意识的点击，提供一个更好的体验。

大多数的组件和周围的细节都是通过设计师和开发者配对来设计构建的，通过合作，我们为每一个新的特征或者设计组件的思路逐渐成熟，经过特征讨论和回顾、实现、最后的抽象化和文档化。这使得内部工具的开发相当地流畅，避免了特征的变动和代码的膨胀，而且帮助我们弄明白了不仅仅是如何在Bootstrap中去使用一个组件，而是为什么要使用它。

自然而然衍生出了新的特征并且融合到现有特征里，有些功能特征我们已经需要修改或者移除，我们遵循同样的步骤：构思、审查、实现、文档化。继续这个例子，我们收到了大量的围绕下拉菜单，并且重新考虑支持多层次菜单。只从网页应用越
像桌面应用——同样使用多层次下拉菜单，这让我们觉得支持多层次变得很有意义。我们收回了早期的决定，但这个过程让我我们保持坦率的、目的明确的、并且对我们客户和他们的需求负责。

几乎我们所有的特征都是通过这个流程开发的，导致我们所做的决定已经超出了仅仅只是构建这样一个工具的范围。我们与那些没有接触到我们的工作流程或者没有深刻理解的人必须进行有效地沟通。

我们在忙于创建一个产品路线图和决定一个项目的目标的时候，我们会积极考虑其他人如何使用相同的组件。对组件的抽象化和文档化串联起了我们构建Bootstrap的整个流程。总体来讲，我们节省了时间和精力，更清楚地讨论了添加（删除）一些特征，并且使我们在未来能够应对更大的项目。

在最初的几个星期的开发之后，我们开始考虑把这个动态文档做成工具包指南风格。我们通过Bootstarp工作中的沟通来达成我们的目标，这也使得Bootstrap快速地成长并且每个人都能使用它。

创建指南型风格的Boostrap的想法很自然地在我们的设计和开发过程中冒了出来。Bootstrap帮助我们用实例文档化容器，而且他们本身支撑整个文档，定义了真正的组件和模板。这也成了设计师的参照点，并且为每一个活的组件创建了文档。
构建指南型风格的Bootstrap在早期就改变了Bootstrap的发展方向，它让我们想去实现项目之外的东西。我们不想把自己限制在设计开发单个项目，我们有更大的目标，我们没有把自己定位成只是想从这个工具中收益，我们的目标不仅仅是在Twitter使用，而是能够被任何的设计者和开发者使用。任何人都能克隆和下载源代码，

灵活的文档促使我们不仅仅是分享整个框架，而是为所有想使用Bootstrap的人提供一个书面和交互式的文档。允许任何人克隆和下载源代码，使用Inspector或者在浏览器中查看源码。
随着工作的推进，“帮助牛b的人干牛b的事”成为了指导我们工作的准则。这显然与我们想帮助那些没有理解过程和产品而进行设计开发的人做决定的目标相吻合，无论是在哪个技术层级或者工作流程的人，人们打开这个文档，就能够使用Bootstrap快速构建自己喜欢的东西。
--(未完待续)