网页设计中的控制幻觉(2018)

我们都想构建强大的、引人入胜的网络体验。我们仔细检查互动的每一个细节。我们花了几个小时把动画秋千拍得恰到好处。我们重构了我们的JavaScript，将加载时间减少了一小部分。我们完全可以控制一切，但残酷的现实是，我们控制的东西比我们想象的要少。

上周，两件事再次提醒我们，道格拉斯·克罗克福德(Douglas Crockford)宣布网络是“可以想象到的最具敌意的软件工程环境”是多么正确。这两个网站都严重到足以关闭整个网站-实际上是数百个完整的网站，事实证明。两者都是可以避免的。

在理解我们控制什么(和不控制什么)的过程中，我们将为我们的用户构建有弹性的、有吸引力的产品。

这些事件中的第一起涉及Chrome 66的发布。在那个版本中，谷歌实施了一个安全补丁，对那些没有注意到的人产生了严重的影响。您可能还记得，由赛门铁克公司的PKI颁发的相当多有问题的SSL证书从去年年初开始浮出水面。显然，赛门铁克在没有提供大量监督的情况下，转包了创建证书的工作。长话短说，Chrome团队认为，对于这些潜在的伪造(和威胁安全的)SSL证书，最好的做法是为接受它们是安全的设定一个“生命终结”。他们将Chrome66设为分界点。

因此，当Chrome66推出(对几乎所有人来说都是自动的、透明的更新)时，突然之间，任何在这些证书上运行HTTPS的网站都不再被认为是安全的。如果有问题的证书针对的是我们的主域，那么这将是一个大问题，但这也是一个问题，因为它针对的是我们正在使用的CDN。您知道，我的服务器可能运行在有效的SSL证书上，但是如果我的资产-图像、CSS、JavaScript-托管在不安全的CDN上，浏览器将阻止这些资源。就像CSS裸体日又一次重演。

老实说，直到迈克尔·斯佩莱西在Twitter上告诉我这件事，我才真正注意到这一点。他雇主的两百个网站立刻就变成了普通的旧的语义HTML。无CSS。没有图像。没有JavaScript。

第二个事件实际上非常相似，因为它还涉及SSL，特别是jQuery的CDN使用的SSL证书过期。如果站点依赖CDN提供HTTPS托管版本的jQuery，则其用户不会收到它。如果该站点依赖于jquery才能使用…。哦，哎呀！

无论如何，这已经不是第一次发生这样的事件了。就在短短几年前，天空宽带的父母过滤器戏剧性地将jQuery CDN错误分类为恶意软件的来源。有了这一指定，他们花了大半天的时间阻止该域上的所有资源请求，几乎影响了他们所有的客户。

对这样的消息不屑一顾是很容易的。当然，如果我们负责的话，我们会做出更明智的实现决策。我们当然会像好的样板告诉我们的那样，包含jQuery的本地副本。问题是，即使有了额外的保护措施，当谈到为网络建设时，我们也陷入了一个最具吸引力的谬论：我们拥有控制权。

在网络上我们确实可以控制一些事情，但它们可能比你想象的要少。作为单独的开发人员或团队领导，我们对最终构建我们站点的HTML、CSS和JavaScript代码有相当大的控制权。我们使用的工具和我们选择的主机解决方案也是如此。当然，在大型团队或当其他人发号施令的时候，这种控制会减少，尽管在这些情况下，我们仍然知道我们正在使用的编码约定、工具和托管环境。然而，一旦我们精心设计的代码离开了我们的服务器，所有的赌注就都泡汤了。

首先，我们并不--至少在绝大多数情况下--控制我们的代码所遍历的到达用户的网络。理想情况下，我们的代码采用优化的路径，这样它就可以快速到达目的地，而该路径上的任何一个服务器都可以读取和操作代码。如果你听说过“中间人”攻击，那么它们就是这样发生的。

例如，某些提供商毫不犹豫地将他们自己的广告插入到您的页面中。很恶心，对吧？HTTPS是阻止这种情况发生的一种方法(并防止服务器能够窥探我们的流量)，但一些提供商甚至已经找到了绕过它的方法。叹气。

假设在传输过程中没有人接触我们的代码，那么在我们的用户和我们的代码之间的下一个障碍就是浏览器。这些应用程序是我们建立在网络上的体验的门户(和看门人)。而且，尽管在过去的十年里，浏览器供应商围绕网络标准达成了一致，但仍有不同之处需要考虑。这些差异是决定我们用户体验成败的另一个因素。

虽然每个浏览器供应商都支持标准的想法和正在进行的开发，但他们都是按照自己的步调来做的，并且与他们的业务利益密切相关。他们优先考虑那些帮助他们实现自己目标的功能，并且有时不愿意或很慢地实现新功能。偶尔，就像CSS Grid发生的那样，每个人都很快就上手了，我们可以看到一个新的规范在一个日历年内从草案到实现。其他浏览器，如Service Worker，可以在少数浏览器中快速站稳脚跟，但在其他浏览器中需要更长的时间才能推出。还有一些，比如指针事件，可能会被广泛实现，但只会因为一个浏览器的冷漠而受到破坏。

所有这些都是说，浏览器景观很像美国中西部的大平原：从远处看，它看起来非常平坦，但穿过它，我们肯定会跌跌撞撞地走进一两个草原狗的洞穴。为了成功应对浏览器环境带来的挑战，熟悉这些洞穴的位置是值得的，这样我们就不会失去立足点。对象检测…。字体堆栈…。媒体查询…。特征检测…。这些工具(甚至更多)帮助我们确保我们的工作不会在不太理想的情况下失败。

除了标准支持之外，重要的是要认识到某些浏览器包含可能会影响代码交付的优化。Opera Mini和亚马逊的Silk就是通常被称为代理浏览器的浏览器类别的例子。代理浏览器，顾名思义，将它们自己的代理服务器放置在我们的域和最终用户之间。他们使用这些服务器来做一些事情，比如优化图像、简化标记和丢弃不受支持的JavaScript，以减小我们页面的下载大小。代理浏览器对按位付费下载的用户有很大的帮助，特别是考虑到我们每年都倾向于增加网页大小。

如果我们不考虑这些浏览器如何影响我们的页面，我们的站点可能会像一只晕倒的山羊一样在空中崩塌和张开双脚。考虑一下取自我在Codesen上吐出的一个示例的JavaScript：

Docent.body.innerHTML+='；<；p>；对于(let i=1；i<；=4；i++){document.body.innerHTML+='；<；p>；'；+i+&39；；&p>；/p>；'；/p>；'；{document.body.innerHTML+='；<；p>；'；/p>；/p>；'；/p>；

此代码旨在将几个段落插入到当前文档中，并在执行时生成以下内容：

很简单，对吧？嗯，是也不是。您可以看到，此代码使用了关键字let，该关键字是在ECMAScript 2015(也称为.。ES6)以启用块级变量作用域。它将在理解let的浏览器中发挥作用。然而，任何不理解let的浏览器都不知道该怎么理解它，也不会执行任何JavaScript-甚至不会执行它们理解的部分-因为它们不知道如何解释程序。Opera Mini、Internet Explorer10、QQ和Safari9的用户将一无所获。

这是一个相对简单的示例，但它强调了JavaScript的脆弱性。英国的GDS进行了一项研究，以确定有多少用户没有获得JavaScript增强功能，结果发现，在本应获得增强功能的用户中，0.9%的人(换句话说，他们的浏览器支持JavaScript，但他们没有关闭)出于某种原因没有这样做。加上浏览器不支持JavaScript或关闭了JavaScript的0.2%的用户，非JavaScript用户总数为1.1%，或者说每93名访问他们网站的人中就有1人是非JavaScript用户。

值得记住的是，浏览器必须理解我们的JavaScript的全部内容，然后才能执行它。如果我们自己编写JavaScript(尽管我们都偶尔会犯错误)，这可能不是什么大问题，但当我们包括第三方代码(如JavaScript库、广告代码或社交媒体按钮)时，这就成了大问题。这些代码库中的任何一个错误都可能给我们的用户带来问题。

浏览器插件是第三方代码的另一种形式，会对我们的站点产生负面影响。它们是我们不常考虑的。回到20世纪初，我记得我花了几个小时试图诊断我的一个客户报告的网站问题，结果发现只有在使用特定的插件时才会出现这种情况。愤怒和自我怀疑在我身上肆虐，因为我一次又一次地未能重现我客户正在经历的错误。我花了两个小时来到她的办公室，坐在她的办公桌前，发现了她和我的设置之间的区别：第三方浏览器工具栏。

我们不能奢侈地跑到用户的家里和办公室去确定浏览器插件是否以及何时阻碍了我们的创作。相反，针对浏览环境的未知数的最好防御是始终使用普遍可用的基线来设计我们的站点。

不管到目前为止讨论的一切，当我们精心制作的网站最终到达目的地时，它还有一个潜在的成功障碍：我们。具体地说，就是我们的用户。更广泛地说，是人。除非我们的产品完全是为其他生命形式或机器的消费而创造的，否则当我们把它让给别人时，我们必须考虑最终失去控制权的问题。

在我为客户创建网站的20年中，我的脑海中总是回想着办事员兰德尔·格雷夫斯(Randal Graves)的哀怨之声：“如果这份工作不是他妈的客户干的，那就太棒了。”我对此不高兴。这是一个傲慢的立场(当然)，但也很容易陷入其中。

人们是如此的贫穷。如果我们能专注于自己不是很棒吗？

当我们为像我们这样的人设计和建造时，我们排除了所有与我们不同的人。这就是大多数人。我要在这里戴上我的公务帽-费多拉？保龄球手？大礼帽？-并说人为地限制我们的客户群可能不符合我们公司的最佳利益。这不仅会限制我们潜在的收入增长，而且如果我们成为被排除在外的一方法律诉讼的目标，实际上可能会减少我们的收入。

我们在网络上建立强大体验的努力必须考虑到实际使用它们的人(或可能想要使用它们的人)。这意味着确保我们的网站为那些经历了运动障碍、视力障碍、听力障碍、前庭障碍和其他我们在“无障碍”标题下汇总的东西的人提供服务。这也意味着要确保我们的网站在各种环境下都能很好地为用户服务：大屏幕、小屏幕，甚至是中间的屏幕。通过鼠标、键盘、手写笔、手指，甚至语音。在黑暗的、没有窗户的办公室里，在玻璃墙的会议室里，在外面的正午阳光下。通过高速的光纤和缓慢得令人痛苦的蜂窝网络。无论人们身在何处，无论他们如何访问Web，都需要进行任何特殊的考虑以适应他们的需求(…。我们应该开发我们的产品来支持他们。

这可能看起来要求很高，但考虑到这一点：消除一个群体的访问障碍会产生深远的连锁反应，使其他群体受益。路边路缘切割是我们经常引用的一个例子。它最初是为轮椅通道而设计的，但推着婴儿车的父母，骑自行车的孩子，甚至是沿着第七大道拖着一塔亚马逊盒子的UPS快递员，都从这个相当简单的考虑中受益。

也许你更喜欢数字。如果是这样的话，请考虑设计您的界面，以便只使用一只手臂的人更容易使用。在美国，每年约有2.6万人永久丧失上肢的功能。与总人口近3.26亿相比，这只是杯水车薪。但那是永久性的损伤。还有另外两种形式的损害需要考虑：暂时性的和情境性的。摔断胳膊可能意味着你的那只手--可能是你的优势手--在几周内无法使用。每年大约有1300万美国人遭受这样的手臂损伤。抱着婴儿是一种情境障碍，因为你可以把它放下，然后重新使用你的手臂，但这种做法的可行性可能在很大程度上取决于婴儿的气质和睡眠时间表。每年大约有800万美国人欢迎这种损伤-尽管它可能是甜蜜和可爱的-进入他们的家，而且这种特殊的损伤可以持续一年以上。所有这些都是说，设计一个单手可用(或通过语音)的界面可以帮助2100多万美国人(约占总人口的6%)有效地使用你的服务。

最后，从很多方面来说，这就是我们使用的副本。清晰、写得好、恰当的文案是网络上伟大体验的基石。当我们起草副本时，我们应该很好地理解我们的用户之间是如何交谈的。这并不意味着我们应该在我们的法律术语中加入俚语，但它确实意味着我们应该创作容易理解的文本。它应该写在适当的阅读水平，没有不必要的行话和习语，无论是母语人士还是非母语人士都可以理解。依偎在我们(希望)语义的、服务器呈现的HTML的温柔怀抱中，我们编写的副本是我们网站仅有的体验之一，我们几乎可以保证我们的用户将拥有它。

认识到我们精心设计的体验可能会以各种方式变得无法使用，这可能会让人非常沮丧。没有人喜欢把时间花在思考失败上。所以不要。不要把注意力集中在所有你无法控制的坏事上。把重点放在你能控制的事情上。

从简单的开始。进行防御性编码。用户-测试它的真面目。认清混乱。拥抱它吧。并建立弹性的网络体验，无论互联网向他们抛出什么，都会起作用。