比敏捷更快——实时 XML 文档

当今时代,大多数技术信息都通过网络发布,但用来发布这些内容的技术仍是旧时代的产物。以书籍形式发布资料的历史太过悠久,习以为常后我们就很难再想象出其他方式。于是我们就裹足不前,照搬其他业务领域的敏捷方法,抱着乐观的希望期盼能有不错的效果。然而,不管您指派多少名 Scrum 专家,定义的 Sprint 迭代周期是长是短,亦或您每夜一次的生成工作能够多么精妙地自动完成,所有整体式发布策略迟早都将分崩离析。

内容时代已经到来。我们生活在一个随时随地都有消费者请求获取内容的时代。内容消费者不断提高要求 – 他们要求的不是更多内容,而是更符合当地情况、更加个性化且在技术上更为先进的内容。我们从平面手册一路走来,历经 PDF、网页、响应式 HTML5 以及嵌入式智能帮助功能。而最近,互联网的非人类用户数量已然超过人类用户。所有这些用户都需要更快地获得更小片段的信息。

面对这些发展变化,我们需要采取新的方法来发布技术信息。有了 Google,谁还需要目录或索引呢?而如果信息由应用请求获取,并处理成形状和颜色,让用户比费力阅读信息更快地领会它们,那么谁还需要 Google 呢?甚至是两周一次的更新周期也无法再满足需要。内容时代需要以一种全然不同的方法来发布技术信息。

摒弃书籍思维。如果更正一处拼写错误后需要重新发布整个文档集,显然并不是一种高效的内容处理方式。这会导致网上文档中的大多数页面均包含与原来完全相同的内容,只是换了新的时间戳而已。这种情况下,浏览器及其他自动化进程需要重新加载这些页面,并将本地内容替换成完全相同的副本。此外,面向所有目标设备和受众发布整个文档集很可能会逐渐成为越来越繁重的任务,让您根本无暇处理。那么,将所有这些不同的个性化文档集都存储在网络服务器上呢?这样的话,每新增一个角色或条件,所需的存储空间都会增加一倍。

上述所有问题的解决方案并不是在内容制作过程中运用敏捷方法、购买更快的硬件来处理自动化发布过程,以及订购更大的磁盘来存储所发布的映像。这些措施只会短期奏效,因为它们天生就不可扩展。最终,仍会故态复萌。

唯一可以真正让这种情况有所改观的解决方案就是摒弃我们熟悉的书籍模式,转向实时发布模式。之所以先将 XML 内容转换成 HTML5 格式,再将其传送到用户设备上的浏览器,并不是出于技术考虑。如今的网络服务器在技术和处理能力上都足以在用户请求获取一项信息时即时完成到 HTML5(或其他格式)的转换。按需发布才是王道。一次只发布一个页面,甚至是一次只发布一项内容,因为用户可能是只需要文档集一小部分的应用。

自从将媒体查询纳入到 CSS 中以及之后开发出了 Bootstrap 等库,网络世界就是响应式设计的天下了。响应式网页设计的原则是“移动优先”。但媒体查询真正实现这一目标了吗?它们所能做的只是隐藏某些内容,或者将高分辨率图像替换成低分辨率图像。但所有内容仍然都需要传送到智能手机,只不过隐而不见而已。

按需精益发布“实时 XML 文档”这种模式的其中一项优势在于,可以根据请求获取信息的用户的情况来调整发布过程。根据用户的屏幕大小、地理位置、授权情况等,转换过程可以挖掘出所需的数据并将其转换成所需类型的媒体。无需再保留双份信息集(一份供最终用户使用、一份供服务人员使用;或者一份供美国使用,一份供欧洲使用;等等)。如果转换过程可以从 XML 源代码中挖掘出所需的数据且这些数据同样包含人类用户可读懂的文字,那么还有何必要为物联网创建一份单独的数据集呢?

采用自适应设计时,系统会根据请求获取内容的用户的情况对内容进行调整,然后将调整后的内容传送到发出请求的设备。借助“实时 DITA 文档”方法,无需再创建多个并行网站。系统会根据网页请求中的数据来选择对相同 XML 内容执行的具体转换。按需发布实现了真正的自适应设计,同时又无需预先发布整套用户可能请求的网页集。

进行实时编辑和审阅。通过将 XML 内容发布到服务器上,所带来的机会不止是催生了自适应设计,尤其是在当今时代,所有浏览器都支持 HTML5,而 HTML5 允许在浏览器内编辑内容。利用另一项称作 AJAX 的标准技术,浏览器可以将更改后的数据发回给服务器,在服务器上这些数据会与原来的 XML 整合在一起,形成更改后的版本。借助这项技术,甚至可以在智能手机上更正发布到实时 DITA 文档网站的内容中的拼写错误。