前言

在产品的整个实现过程中，有两种情况可以请（或者说需要）一些用户参与进来：

• 概念形成或叫需求确定阶段：此时的大方向通常已经定了，但会有些“想不清楚”的细节问题。那么可以使用“焦点小组”或“特约用户”的方法对用户进行概念测试，从而达到在产品设计阶段验证团队想法的目的。方法就是在项目的开始阶段邀请至少六位目标用户（目标用户指的是对核心概念认可或者说他刚好就有核心概念所提及的需求，他不能是对核心概念一无所知的）来针对一些问题进行讨论，明白他们的真实意愿。比如我们产品（全携通）的核心概念（目前）是：团队用户的文件存储分享和协作。这是大方向，但具体要怎样来进行分享和协作需要在搞清楚了目标用户的真实使用场景后才能来设计具体的功能，以帮他们达成所愿。『焦点小组』即是帮忙确定真实的用户场景的一个很好的方法。
• 易用性测试阶段：同样要邀请至少六位的目标用户（同样不能对核心概念一无所知）来对核心功能中的交互设计进行测试，以帮助改善易用性。显而易见，我们此次的测试或体验属于（“接近于”更恰当）『易用性体验』，其实它应该有一个很重要的前提是：受试者有这方面的需求，或者至少要在测试之前对核心概念能有足够的了解，这样才能保证测试中所安排的任务是尽可能接近测试者经常遇到的问题或者说其真实意愿（严格来做的话，必须要邀请到目标用户才有意义，而且要越早越好，有的甚至在 UI 设计阶段就会邀请他们参与进来）。

分析与总结

这次产品易用性体验会老实说全程都被吐槽，但很多槽也非常准确地吐到点上，我们从中收集到了不少有价值的信息用以提高我们产品的『易用性』（换一个词就叫『体验』）。但我们必须认识到的是这样的体验或测试并不是用来获得这些易用性测试者的需求（事实上也获取不到，倒是平常就在使用这类产品的陆同学当场表示以后会使用全携通，他才是里面最明显的目标用户，所以他也给出了颇多的正面反馈），而是在我们已经提供了这些功能的前提下，请他们来测试它们的易用性而已，看看对一个完全的新手来说是不是能够非常容易上手。基于这个前提，我对所搜集到的信息做了些分析和总结，并提出一点个人的浅陋看法：

排除操作任务指导中的限制性预设产生的问题

比如在生成链接并分享的任务中，我们限制了体验者必须将访问权限设置为『只能预览』（当然我们的初衷可能是希望他们能感受到我们的权限控制功能），而这跟我们的默认设置（允许下载，无需访问密码，不会自动失效）不一致所以体验者需要重新更改权限再分享，所以其中便有人觉得麻烦希望能先设置好权限再生成链接。但其实这样的预设并不能算作真正的使用场景，行业内领先的竞品们的做法都是按照最常用的权限（『允许下载，无需访问密码，不会自动失效』）作为默认值直接生成链接，只有在特别需要有安全方面的顾虑的时候才会需要去更改权限，竞品们这么做除了有数据的支撑外，更重要的是这里可以作为一个诱导免费用户付费升级的一个重要转化点，当免费用户在分享文件时需要安全方面的考虑的时候，比如他希望设定一个自动失效的时间，设置一个密码，甚至可能不希望被访问者下载，于是他进入到『链接设置』界面，此时他才发现原来免费用户的这些功能全都是无法使用的，而他又急需它们，这样他便有更大的概率会进行付费。这个『付费转化点』找的可谓是相当准确，反过来允许先设置权限再生成链接的话这个『付费转化点』便无法成立了。所以我仍旧坚持现在的做法（之后也会把提高付费转化率作为一个重要的项目来实施，它的关键就是要找到这样一个个让人不得不付费的地方）。所以诸如此类因为预设条件所得到的使用反馈是我们要坚决排除掉的，不加分辨地采纳任何意见是相当危险的做法。

谨慎对待个人观点

比如关于讨论这样的及时通讯模块，其中的一个体验者说这个功能完全不需要，用 QQ 就可以了，如果我们就这样下结论说立马砍掉它的话，那这种通过个案来论证结论的过程是相当不严谨的，如果这种论证成立的话，我这边刚好可以举出截然相反的例证：有道云协作的产品团队在他们的产品上创建了一个产品吐槽建议群（就类似于全携通的协作文件夹），旨在搜集用户反馈，我就常常看见有人留言说有道云协作这样的讨论功能好好用，他们团队基本上就用它来沟通工作，甚至还有人希望增加讨论的显示面积与重要性，他们认为文件反而应该放在更次要一点的位置……那我是不是就能因此证明说讨论功能非常有用？

其实这种时候任何的主观判断都是没有意义的，我们应该通过最理性的东西——数据作为最高的指导标准，一个功能只要它的场景是合理的就可以大胆地实现它（其实我们每天都在践行着这个场景，它会跟独立的 IM 会有不同，我们上传或更新了文件，全携通便自动推送一个相应的动态，我们也可以顺便留个言，描述一下相关情况，比起打开 QQ 再去沟通，这一切难道不是更加自然而便捷吗？这个过程可以完全省去啰嗦麻烦地描述『全携通的什么文件夹下的子文件夹的某个子文件夹下的一个什么文件怎样怎样了』），紧接着要做的事情是对它的数据进行监控，一段时间（比如一个自然月）后如果数据显示用户频繁使用了文件管理与分享功能，而讨论这一块却几乎不用，这个时候我们才可以得出结论用户不需要它所以应该果断将其砍掉；而如果数据还不错的话，我们应该继续优化它。

举这个例子是希望随着用户数的增加，我们能逐步提高对数据的关注度，对一个互联网产品来说，数据就好像是导航系统，是能够帮助产品找到正确方向的定位工具。

共性问题非常具有价值

虽然这次的体验者可能有的并不是我们的目标用户（其中一部分的体验者没有使用过这类产品的经验），但他们反映出来的一些共性问题还是能很好地说明我们全携通目前的易用性问题的（根据人机交互博士 Jakob Nielsen 提出的可用性问题发现率曲线，6到9个即能反应出90%左右的问题）。我们会认真总结并据此在将来一一优化我们的产品（全携通）。

微信常常让我感觉烦躁的体验之一在于它的聊天记录不能像 Google Hangout（以前叫 gtalk）那样在各个端之间进行同步，更准确的说应该是它不支持将聊天记录自动存储到云端，用户无法方便地通过任何设备来取回或查看完整的聊天记录。这导致我在切换手机使用或在电脑上使用微信时对话总是缺少完整的上下文，而在电脑上则干脆连聊天记录都不曾留下。而我常有更换手机使用的习惯，可能几天想用 iOS，过几天又会换用 Android （原生系统）。有一次我在笔记本上（微信客户端）与老板沟通过一些工作上的事情，当时使用的是 Android 手机来进行登录操作的，再后来某天我上班时将 Android 手机落在家里，而当天的工作我需要先确认一下之前跟老板的沟通记录，打开笔记本上的微信客户端没有留下任何聊天记录，再打开 iPhone 上的微信同样缺少那一段消息，而老板又在出差，打电话跟他确认又怕他怪罪我做事情太过马虎，当时我的心境真可谓是搔首踟蹰而无所适从......

说完了故事，接下来我试着简单分析下微信没有支持该聊天记录同步功能的原因。

首先，从开发一个功能的目的或者说它所能带来的收益预期的角度来考虑。假设微信的产品团队在衡量一个功能优先级是否够高，是否要付诸开发的标准包括：是否能增加用户数，是否能增强用户粘度，以及是否能提高用户体验。同时满足这三个条件的功能优先级自然就高，满足较少或者不满足的功能自然优先级较低甚至不会被考虑。聊天记录同步的功能不能迅速传播所以无法增加用户数，比起便捷的沟通本身或者朋友圈这样的社交属性它也无法增强用户粘度，唯一能做到的只有最后一条提高用户体验，所以它自然不如朋友圈那样三个条件均能满足的重要功能，其优先级毫无疑问会被排得很低，甚至在很长一段时间内都不会考虑实现。

其次，再从用户需求的角度来分析。微信上的聊天内容大多还是偏向朋友熟人间的闲聊（说完就过去了），对于这样的用户来说，记录是否存储到云端是否还能进行同步他们并不会很在乎；更有些聊天内容涉及隐私等敏感信息，为其存储起来反而让人觉得不安，有时还得颇费心思删除干净，所以他们也不会需要这样的功能；此外，微信的使用场景大多还是偏向手机这样的移动设备，而大多数用户贴身常用的也只不过是一部手机，所以他们对于能在多个设备间同步聊天记录的需求并不迫切。所以，这样的功能不是在大多数情况下被大多数人所需要的，故微信目前便不会考虑进行开发。

写到这里我本来想继续从技术实现难度和硬件成本的角度再来个收尾，于是便去 Google 了一下聊天记录云存储的问题，然后即便是毛寸短发我的也不得不瞬间凌乱了。原来微信（V6.2.3）已经支持“聊天记录迁移”，官方所描述的用户场景是这样的：聊天记录可以快速导入到新手机，不用担心换手机后聊天记录的遗失。嗯，这的确是一种解决同步问题的方式，但所幸跟我想要的“同步”却不是完全相同的概念，并没有涵盖到所有的用户场景，就好像我之前提到的自己的故事，当时跟老板沟通过之后既没有想到要备份到云端，也不觉得需要将聊天记录导入到另一只手机（因为当时的我不可能预料到会将手机落在家里，也并不知道还有这个功能）；而微信官方描述的场景更多的还是说的是当用户更换新手机时可以将旧手机的记录导入进来，并不是我所描述同时使用两部（或多部）手机并时常切换使用的情景，在我所遇到的那个窘境中，微信的解决方案对我已经无力回天，但如果能换做是 Google Hangout 就完全没有任何问题啦。与此同时，微信还支持“通过云端迁移”的功能，旨在让用户可以选择某些对话上传到云端，然后在规定的时间内再下载下来，其实这也不是真正的云同步。故此，我所说的这些也不能算是毫无意义。

那么，接下来我想尝试提出自己的解决方案。

前面说过，这不是一个人人都需要的强需求，再加上用户基数如此巨大，直接像 Google Hangout 那样默认云同步所有聊天记录的做法，一方面是增加成本，另外也会给一部分用户带来麻烦（他们希望聊过即焚，不留痕迹）。我的解决方案是“选择性同步”它跟微信现有的做法不同，用户可以直接在聊天列表中选择为某些对话开启同步，为了避免用户在进行同步之前已有过一些重要对话而未能存储到云端的情况发生，可询问用户是否同时同步本地已有的聊天记录，是的话就将已有记录也同步到云端，否则就只同步开启后的对话。用户可随时停止同步，顾名思义，停止期间的对话不会进行同步，再开启时可同前那样进行询问。如此，对于同步过的对话，用户登录任何设备（包括手机、平板以及电脑等）的微信客户端时，会自动将所有设为同步的聊天记录同步下来。而对于进行过同步的对话，在删除消息时可询问用户仅删除本地的对话（未同步的部分）还是删除所有（包括云端）。如此一来，既可以不必为了闲聊等的对话浪费资源，又能为工作沟通之类的重要对话进行同步。我认为是比较好的解决方案。

前言

做产品应该要有自己的一套逻辑在，简单来说，某个功能为什么要这么做，我们应该要能清晰的解释出来，并且它必须服务于产品所要解决的核心需求，逻辑之间不可以相互矛盾。

一个案例

针对产品中采用多种色彩做区分的问题，很难说清它的好坏，我先以自己的亲身体验着手，试着来剖析这个小细节。

Google Keep 采用了可选择多种颜色的卡片设计，再加上各个平台间的同步，用来做记事本之类的工具真的非常方便，而且一开始我觉得彩色卡片很有意思，几乎大小事情都靠它，不论是工作计划还是出门的公交路线记录。 因为它提供了颜色选择，那么我自然想到应该使用不同的颜色来对我的事务做分类，想来想去，最后决定用红色记录工作内容，绿色则用于标示私人的事情（诸如出门路线图，读书笔记之类），最初还挺和谐，渐渐就变得困扰起来，尤其是我不再使用Google keep 做工作日程安排后，对卡片颜色的选择就变得略微踟蹰了，每次创建笔记时我总是对应该选用哪种颜色犹豫再三，即便做了分类标准还是会对当下的事情到底属于哪一类有 决定困难症 ，于是我渐渐不再按分类来做了，而是依据页面上的颜色平衡来做取舍，而这样做也同样会导致选择时的犹豫不决，更何况会使笔记显得毫无秩序可言，到最后，我几乎就懒得再去纠结颜色了，不论是出行路线，约会地点，购物清单还是读书笔记，统统都是默认的白色。

简单的分析

我想，这类给用户提供多种颜色可选的小功能，它们的出发点应该是为了方便用户做分类，这本身也是有需要并且有些时候也挺有用处的。而大多数人所倾向的事物应该都是有序的，因为无序往往意味着“难以理解和难以记忆”，所以人们在使用这类功能的时候就会很自然的对所要处理的事务进行分类（随随便便使用颜色会为所处理的事务带来混乱，增加认知和记忆的难度），而分类的过程其实有点折磨人，并且在之后的颜色选择中也会令人犹豫再三，因为很多类型的事务往往度是模凌两可而难以抉择，此是其一；

其二，即便自己克服了选择困难，为文件做了坚决的分类并指定了相应的颜色，但对于协作型产品来说，你还必须面临的一个困扰是如何将自己的分类标准准确的传达给你的伙伴，才不至于给你们的协作造成困扰。否则多人的选择困难症叠加形成的混乱将成指数级地增长。

最后

其实写这个并不是为了证明“选择颜色”的对错，只是希望说明一点，我们在做产品时，不能想当然地去叠加功能，而是在理解其逻辑的基础上来做取舍，因为哪怕是这样一个小小的功能，也是有许多的细节要做考量。当然，现在来纠结这个问题的确是过于本末倒置了，对我们的产品来说，应该优先解决好的问题是： 写作 协作 分享 这三大核心功能，只有在这些需求被完美解决后，其余的小细节才有讨论的必要。 Fighting！

引言

最近，我们已经在开始下阶段的产品规划，其中迫在眉睫又争议颇多的一点在于桌面端的实现形式。其实这样忽视目的而直接去讨论产品有哪些功能的做法本身就是不合理的，除了争得“面红耳赤”之外不会得到任何正确的讨论结果。

那么我有必要以做一个产品的思路来重新梳理一下这个问题。首先，做产品的正确流程是这样的：先分析并确定产品所要解决的核心需求（或者说做该产品的目的）；然后围绕这个核心需求对产品做一些阶段性的规划，英文叫做roadmap，翻译成中文就是产品路线图，简单来说就是规划一下“什么时候该做到什么样子”；最后才是为了实现需求而进行具体的功能设计。

所以，我们在“桌面端到底是为了解决什么问题”都没有搞清楚的情况下，就盲目而激烈地讨论起具体的功能来，这种本末倒置的做法因为缺少目的与规则，会放大人们主观臆测的能力，每个人都可能会“捏造”一些需求或者场景，然后再为“捏造”的需求提供“合理”的功能设计。这样做出来的东西怎么可能是正确的产品！所以，这封邮件的目的就是为了理清全携通的桌面端应该解决的核心需求是什么

在确定桌面端所要解决的需求之前，我需要特别申明一下我们全携通所解决的核心需求（产品的目的）—— 群体性用户的文件存储与分享（而根据我们产品的设计，“协作”这件事情在“分享”的时候就自然发生了）。为了实现这个需求，我们又细分出很多的子需求（每个子需求都有对应的具体功能来实现），它们都是为了帮助实现产品的核心需求而存在的。也就是说，我们在做产品的时候并不是简单粗暴的堆砌功能，而是以 是否有助于实现核心需求 为标准来做功能的取舍。桌面端的需求确定自然也应该遵循同样的判断标准。而且，对于我们这样一个基于云计算的文件存储与分享应用来说，不论是网页端，手机端还是桌面端，都只能算是全携通这个产品的组成部分，各自都有其优点和不足，只有将它们组合起来才算是完整的产品，才能为用户带来完整的体验。而网页端与手机端已经实现了许多的功能，并在它们各自擅长或专注的领域上，都提供了不错的体验，但也存在它们不擅长或做不到的地方。那么比起复制一遍其他终端已经完美实现的需求，桌面端不是更应该好好探索一下自身的特点与优势从而弥补产品的不足吗？

不应该考虑的功能

说到这里，可能我们还是不清楚我们应该通过桌面端去解决的核心需求到底是什么。那么，我们换一种思路，采用排除法吧，将不应该做的事情全部剔除。这里有一个判断的参考：如果桌面端加上某个功能后对整体产品的目的没有任何影响的话就应该果断砍掉，比如它做了一个网页端已经完美实现的功能，表面上看着好像东西是增多了，但它其实根本没有实现任何新的需求，只是多提供了一条能够帮助用户实现同样需求的道路而已，就算桌面端不做，用户照样能够完美达到其目的，那么我就认为桌面端所做的这个功能根本就不迫切不核心也就进而不需要（它对实现产品目标没有任何改善）。

所以，我认为桌面端只是把网页端已经实现的功能再重新实现一遍的做法是不可取的，更多的理由分析如下：

• 产品组成部分之间应该相辅相成，各自发挥优势，同时又弥补对方的不足，它们配合在一起使用应该起到的是加法的作用，解决用户需求的同时更能提供优雅的体验；而如果以部分人不喜欢用网页为理由，将桌面端做成一个“大而全”的东西，甚至开始认为再也用不着网页端了，那就真的犯了一个严重的错误，它使得产品的组成部分之间出现对立与排斥的现象，不再是相互联系的有机整体，这种产品内部互相残杀的做法对产品本身是非常不利的。
• “用户的个人偏好。。。有些人就是不喜欢用网页”之类的表达其实根本就不是需求（需求的正确表述应该是“我想要做到某件事或实现某个目的，这样我就能如何如何。。。”），正如前面所述，它充其量只能算作实现同个需求的另一种途径，那么以这样一个伪需求为基本前提来推导出需要桌面端复制相同的功能的论证是不成立的。事实上，我们做产品的时候应该关注的永远是与产品目标相关的真需求，只要功能好体验好，任何的用户习惯都是可以被引导和培养的。

桌面端应该专注解决的核心需求

比起直接说出结论，我还是从侧面推导出这个结论更合适。前面也提到过，全携通的网页端有些功能已经做得不错了，但还是在有些需求实现上做得不够甚至很难做到，：第一，虽然我们已经实现的文件预览方案效果真的非常不错，但支持预览的文件格式也不过那么几种，而人们常用的文件格式又何止于此，而要实现文件编辑的需求更是难上加难，即便付出巨大成本终于利用微软的解决方案实现了在线编辑，它能处理的文件类型还是很有限，那么我们其实并没有从根本上解决文件预览与编辑的需求，其实用户对编辑功能的真正需求并不是在不在线的问题，而是方不方便的考量（如果每天重复五次以上的“下载，编辑，再上传”的过程，不用说用户，就连我都想撞墙了，这必然会给产品的易用和口碑造成巨大的杀伤力）；第二，绝对的依赖网络，没有网络就什么也做不了。这两个问题不解决，那全携通就很难说实现了当初定下的核心需求，也正因为在桌面端复制一遍网页端已有的功能的做法对产品现状没有任何的改善，所以应该坚决舍弃。

继续推而广之，由于云计算才刚刚兴起，虽然它有明显的优势－将原先孤立的事物（比如电脑，软件等）通过互联网联系起来，却也有它暂时难以解决的问题，比如跟我们息息相关的文件处理的能力，它能做的真的太有限了。所以，仅仅依靠云计算，根本不可能为用户很好的解决需求，这个时候别忘了还有个人电脑的存在，经过那么多年的发展，个人电脑的处理能力已经足够强悍，正常人会用到的文件类型在电脑上都能找到相应的软件可以打开它，更可以编辑它。我们应该考虑利用个人电脑来解决这个棘手的问题（我们离答案只差一步了），为了利用本地电脑的计算能力,我们要做的只是为用户省掉“下载，编辑，再上传”的繁琐过程，让用户直接在自己的电脑上编辑保存即可，剩下的由全携通默默地将文件的变化上传回云端。

简而言之，就是现阶段云计算的文件处理能力十分有限，而这对于本地电脑来说却是易如反掌，所有云存储有关的服务都不得不向个人电脑寻求帮助，我们的产品同样应该考虑的是如何利用本地端的优势来弥补云端的不足，说得再具体一点，就是要使得云端与本地端能够方便的联系起来，那么答案就是文件的同步，是的，我们全携通桌面端应该要解决的核心需求是本地与云端的文件同步！

最后，我们再来设想一下这样的场景：

在你忙于其他事务的时候，全携通已经默默帮你把云端的文件都同步到你到电脑中了，而当你需要编辑文件时，只需要在电脑上找到需要编辑的文件，然后打开编辑最后保存，全携通又开始默默地将刚才修改地文件同步回云端，同步完成后，你在网页端惊喜地发现文已经更新为最新状态，你回复一条评论“文件已经修改好，请确认”，你微微一笑。

你在出差的途中，在飞机上，想起还有一些放在全携通上的资料需要预习或编辑一下，虽然不能上网，但依旧能在自己的电脑上查看之前同步好的文件，或者做些必要的修改，下了飞机，连上wifi，全携通立刻帮你把在断网期间的所有修改同步回云端，此时，你已经泪流满面。

总结

每个终端其实只是全携通这个产品的组成部分，它们应该专注于各自擅长的领域，同时又能互补不足，网页端将账号的管理分享协作等功能做到体验优良，手机端实现移动办公沟通的需求，桌面端再通过文件同步的方式来解决文件处理的难题，这样的组合方式，我认为是实现产品目标的最优解。

Adobe 的 CSS Regions 和 CSS Exclusions 技术分别用于将文字限定在某个（些）区域里流动或者围绕着该区域来展示。

拒绝这样一个拥有诸多优势的技术方案并不容易，更何况已经答应在先。Google 本已决定使用 CSS Regions 来给 web 页面增添更显精美的杂志风格布局。然而该项技术过于复杂，它极有可能影响到移动设备版的 Chrome 开发进度。根据 Chrome 开发人员 Eric Seidel 的说法，Google 希望大幅提高移动端 Chrome 的运行速度，并将其列入2014年度首要开发项目之中。鉴于以上种种原因，Google 最终放弃了 Adobe 的 CSS Regions 技术。

为了使得 Flash Player 的优良性能可以集成到本地 Web 标准中，Adobe 数年来一直埋头开发 CSS Regions 并取得了相当程度的进展——它已经能够支持 Google 的 Blink 渲染引擎以及 Apple 的 Webkit 项目（Blink 的基础)。然而，Seidel 仍旧打算与 Adobe 方面一起将 CSS Regions 从 Blink 中移除。

“我想 Blink 今年的焦点肯定是要提高其在移动设备的性能表现 ……我已经开始意识到 Regions 并没能很好地兼容目前的性能优化，却反过来影响了我们核心渲染代码的优化和精简。Regions 的确能够解决 Web 平台某些实际的缺陷，可我认为 Blink 需要的应该是更加简单或者是体积更小的弥补那些不足的方案（有 Adobe 的帮助那就再好不过了）。”作为 Blink 项目的领头人，Eric Seidel 在2013年度的 Google 开发者大会上解释了他弃用 Regions 的原因。

Eric Seidel，Blink项目的领导者之一，在2013年Google I/O上发表演讲

CSS Regions 的支持者们对此决定非常不满，而且反弹强烈，他们回应说该项技术包括与它相关的另一种方案 text fragmentation 都是大有用处的，而 Google 如此严苛的决策方式会极大地阻碍人们对 Blink 的贡献。与此同时，Adobe 也在极力扭转 Google 的态度。

“我们承诺会跟你们一起努力，修复那些缺陷，并保证 regions 代码绝不会拖累 Blink 的2014年度开发目标。” CSS Regions 项目组的 Mihnea Ovidenie 和 Andrei Bucur 说。

然而这番承诺收效甚微。Google Chrome 的另一位开发者 Adam Barth 表示，他更期望 Blink 能够良好运行基于 Web 的应用，这样开发者们才会更多地投身 Web ，而不是像 iOS 的 Cocoa 那种移动软件基础。

“并不是说我一点儿也不在乎能否在浏览器上拥有书籍或杂志那样的阅读体验，比起这个我更关心的是要把 Web 转变为更能吸引应用开发的平台，超越 Cocoa。” Barth 周六这样说道。

在低端设备上浏览器也能有较好的性能表现，这是 Google 2014年 Blink 项目最优先的目标。

“Blink 毫无疑问要成为性能最佳的移动 Web 引擎，” Seidel 阐述了其开发的目标。它不但要获得最高的测试评分，还要实现最低的性能消耗，占用更少的内存，同时能更快地加载网页和应用，滚动页面或者显示动画效果时可以流畅地刷新屏幕。

原文：Reversing course, Google rejects Adobe Web publishing tech

自学了一点前端开发之后，为了学以致用，也想将那些零碎的知识贯通起来，真正做一个略微大些的项目，便利用 github 的 pages 搭建了这个博客。具体的搭建过程和概念的解释可参考这里。值得一提的是，我在搭建博客的时候创建的是这样的 repository：tiemuxu.github.com，并在 master 分支下做所有操作。建议新手可同时参考另一篇精简的文章，或者自行 Google ，相信最终都能够将自己的博客搭建出来。这里就不再赘述。

在开发过程中，需要将代码 commit 到 github 上，才能查看效果。因此常常发生的情况是，新的 commit 只是为了修复上一次的某些零碎 bug，如果人再粗心点，提交代码后才发现还有漏网之鱼，于是还得再来一次，如此反复。导致 github 上的 commit 历史很难有 milestone 式的版本记录，同时也增加了开发的繁琐度。那么在本地配置开发环境就显得尤为必要了。github 使用 jekyll 来将网页源码转变为网页。因此，所需的开发环境就是本地的 jekyll。

首先，需要安装 Ruby 环境和 RubyGem。最简单有效的方式是使用 RubyInstaller，下载安装即可（我安装的是最新版本 Ruby2.0.0-p353）。

然后，还需要安装 Development Kit(DevKit)，同样选择合适的版本。下载后运行该 exe 文件，将其解压到任意位置，这里建议解压为 'C:\Devkit' ,然后运行 'Start Command Prompt with Ruby'（类似于cmd的命令行控制台），通过命令行安装：

显示如下信息时表示 DevKit 已经安装成功：

接下来，可以安装 jekyll 了，在相同的目录下运行：

最后，再来安装 Rdiscount，用以解析 Markdown 标记。如果使用的是 Textile，则安装 Kramdown：

通过以上步骤，所有的环境和依赖包都已安装成功。进入博客的仓库目录（如 cd tiemuxu.github.com），用下面的命令来启动 jekyll：

本以为能够大功告成，控制台里却出现类似如下的错误提示：

Google 后得知，博客的源代码中包含中文字符，而 Ruby 控制台并不支持UTF-8编码。那么解决问题的思路就很明显了，只需要想办法使其支持就行。 Google 再次帮我找到了答案——在执行 jekyll 命令前，可以用命令将控制台的代码格式转为 UTF-8：

然后终于在控制台里看到成功运行的提示：

可是事情并没有结束，当我满怀期待地在浏览器里访问该地址时，看到的却是 'Not Found' 的错误，郁闷到差点一口老血喷出来。我平静下来想了想，作为技术人员希望事情一切顺利从来就是个小概率事件。如同在开发过程中，不管自己觉得代码写得再如何完美，也总会有 bug 存在。所以遇到问题不要着急上火，而是继续搜寻答案。原来需要把博客代码仓库里的配置文件 _config.yml 中的 baseurl 删除，然后重启服务。谢天谢地，它终于跑起来了，这几乎快要让我“泪流满面”，连在客厅里打电话的室友都以为我疯了，连声问我“何弃疗”。

哦，对了，如果默认的 'server address' 是 '0.0.0.0:4000' 的话，可以到 'C:\Ruby200\lib\ruby\gems\2.0.0\gems\jekyll-1.4.2\lib\jekyll' 目录下修改 configuration 文件，改成自己喜欢的 IP 和端口。到此为止，本地的开发环境已经搭建完毕，之后提交代码或者写了新的文章，就可以先在本地预览，将结果调整到自己最满意的状态，再一次性提交它们，岂不是方便而高效吗？