即使他们在开始旅行之前花大量时间研究要做的事情，但大多数旅行者还是会做出最后的决定。寻找酒店和航班相对容易，但是在旅行和活动方面，问题在于并非总是可以提供最后或最晚的预订。而且，如果有的话，通常很难在网上进行购买。由于许多网站运行缓慢或预订过程漫长而复杂，因此移动体验也可能受到限制。
在本文中，我们将提供一个案例研究，并分享对我们设计和建造的项目GetLocal的观察，GetLocal是冰岛的在线旅行社和预订平台。我们将分享我们如何通过构建具有超快速搜索和针对移动设备进行优化的预订体验的响应式网站来创建解决移动用户面临的多个挑战的预订平台的方法。尽管本文重点介绍旅行，但是设计师和开发人员可以将我们学到的知识应用到任何类型的电子商务和移动搜索中。
正确建立移动电子商务网站
如果您正计划下一个移动电子商务网站，请记住在开始之前要考虑很多事情，以及您需要问自己的问题。
阅读相关文章→
寻找最难解决的问题
我们首先编写一个业务计划，概述要解决的问题。Google的一项研究表明，有85％的旅行者在到达目的地后做出购买决定，而50％的旅行者使用手机进行预订。考虑到这一点，我们构建了满足不同角色的多个用例。我们需要解决的最困难的问题是旅途中正在使用连接速度较慢的移动设备，需要找到具有最后一刻可用性的特定活动并且需要能够在线完成预订的人。
Web表单是每个有意义的交互的中心，因此值得牢记处理。认识Adam Silver的“ 表单设计模式”，这是设计和构建Web表单的实用指南。
跳转到目录↬
功能面板
客户旅行旅程
我们对客户旅程的看法，到达目的地后兴奋和移动使用增加。
想象一群朋友沿着冰岛的南海岸旅行，该瀑布以瀑布和黑沙海滩而闻名。现在是上午10:00，该小组希望借此机会在附近的一个名为Sólheimajökull的冰川进行冰川远足；他们需要找到具有认证的冰川向导的游览，该向导才能在同一天的下午游览中适应他们。他们将手机连接到租车随附的无线路由器，但是在农村，如果能够找到稳定的3G连接，他们将很幸运。他们想在线预订并确保自己的位置。
GetLocal搜索引擎的实际应用
在GetLocal.is上搜索具有多个属性的冰川之旅。
超越移动设计
对我们来说，移动设计超越了视觉设计。我们研究了从渲染速度到内容的每一个方面。从一开始，GetLocal就被设计为移动优先。从第一个线框工程图到Sketch中的高清设计，我们始终将移动体验保持在最前沿。
牢记这一点有助于我们简化导航以及信息体系结构；这也意味着所有元素都是为触摸而设计的，并且我们使用了诸如水平滑动之类的移动设计模式。我们还必须覆盖许多本机表单元素，并用更易于使用的简单菜单替换它们。
预订界面的第一版
您需要单击，滚动并单击以更改成人人数的预订UI的第一个版本。
预订界面的最新版本
当前版本仅需单击即可，并且不需要本机浏览器元素，因此更易于在移动设备上使用。
如果将我们的桌面版本与移动版本进行比较，您会发现我们只是将移动预订表格复制到了桌面版本。那不是计划，但是一旦移动版本制作完成，我们就没有必要为台式机创建不同的体验。
桌面浏览详细信息页面
预订表格查询实时可用性API，并立即通知您每天的可用性。如果出发的座位少于10个，我们会告诉您确切的预订数量。我们通过连接各种库存解决方案来做到这一点。加载产品后，我们将调用API并获取可用的日期以及剩余的座位数。这使我们可以禁用没有库存的日期，并向客户显示剩余的座位数。
实时具有这种直接访问权限为用户节省了不必不必开始预订过程即可发现想要的东西在其首选日期已售罄或不可用的麻烦。
极品飞车
我们希望客户能感觉到我们的网站超快，我们希望缩短1秒的开始渲染时间。这不是一件容易的事，尤其是当您在一个非常漂亮的网站上加载了精美的图片时。
我们挑战了领先的前端开发人员，来自Gateway Technolabs的Alpesh Prajapati，将请求减少了40％，并将渲染速度提高了60％。我们希望比主要竞争对手快四倍。首先，他认为设定这样一个雄心勃勃的目标很疯狂，但是一旦我们开始仔细研究到目前为止所做的一切，我们就一直在寻找改善和接近目标的方法。
在竭尽全力之后，我们聘请了哈里·罗伯茨（Harry Roberts）来审核我们的表现。哈里提供了非常深入的分析，并指出了我们可以做得更好的几个地方。结果，我们修改了缓存策略并重构了一些CSS，从而带来了进一步的改进。
提出更少的请求
我们切换到HTTP / 2以便并行加载请求。但是，由于从服务器到客户端的每个请求仍然需要时间，因此我们通过合并和压缩CSS和JavaScript文件，使用图标的精灵等来减少请求的数量。合并和压缩给更新和发行期间的开发带来了一些开销，但他们仍然值得。
我们还分解了JavaScript和CSS文件，仅加载页面上所需的内容。例如，我们的博客不需要日历所需的CSS和JavaScript。我们还删除了开始使用的一些库，因为我们找到了解决它们的方法。例如，我们放弃了Font Awesome，就这样。
压缩图像并提供最佳尺寸
我们使用了很多图像，但发现Photoshop和Sketch的压缩程度不够高。我们开始通过ImageOptim（仅Mac）传递所有图像，然后将CMS与ImageOptim Web服务集成在一起，以便所有上传的图像在存储并发布到CDN之前都要经过适当的压缩。
通过ImageOptim压缩本文中的高分辨率图像后的结果
通过ImageOptim压缩高分辨率图像后的结果。（查看大图）
尽管压缩图像会大大减小尺寸，但是我们知道根据设备的屏幕尺寸提供不同尺寸的图像会有所帮助。这也使我们能够调整裁剪点，甚至可以将不同的图像提供给不同的设备，以充分利用空间。
我们使用该picture元素在不同的断点处提供尺寸合适的图像。
对于每个图像，我们创建480、780、1200和2560像素宽的版本。我们使用Slack模板以最佳方式定位和裁剪英雄横幅，以适应常见的屏幕尺寸，有时，如果适合的话，可以使用其他图像。
用于横幅广告定位的Slack模板的屏幕截图
我们用于横幅定位的Slack模板（查看大图）
我们预先加载了英雄横幅，并在标题中内联了最合适的尺寸，以实现最佳的尺寸和设计（尽管preload并非所有浏览器都支持）。
我们有来自世界各地的客户，我们希望来自巴西，澳大利亚和中国的客户能体验到与来自欧洲的客户相同的速度。除关键CSS和JavaScript文件外，所有常见文件都存储在Amazon S3上，并通过CloudFront内容交付网络（CDN）提供服务。对于大多数文件，我们将浏览器缓存设置为不可变的，这基本上意味着浏览器将永远不会尝试再次获取该文件。为了打破该缓存，我们更改了文件的版本号。作为不支持不可变缓存的浏览器的备份，我们将有效期定为很远的将来。
复制
我们将Redis用于大多数页面的服务器端缓存，但是我们不缓存所有内容，因为清单检查需要实时进行并通过AJAX进行填充。
当页面加载时，我们：
获取产品详细信息，
加载评论，
调用实时可用性API并填充日历，
最后，加载类似的游览。
在我们的游览详细信息页面上加载AJAX的顺序
在我们的游览详细信息页面上加载AJAX的顺序（查看大图）
内联移动折叠样式
速度与感知能力息息相关。能够在一秒钟内开始呈现页面很重要，因为即使整个呈现时间较慢，它也会给人以快速的印象。
性能测试结果
WebPagetest.org上的性能测试的结果。B级归因于第三方脚本。（查看大图）
我们通过获取部分主要CSS文件（即呈现页面第一部分所需的内容）并将其包含在head模板的模板中来完成此操作，这使浏览器可以开始呈现页面，即使它没有下载了所有CSS。加载CSS文件会导致渲染阻塞，因此我们使用loadCSS异步加载完整样式表。
持续优化-它永远不会结束！
优化有点像节食：一旦达到目标，您就会开始懈怠，忘记优化。速度是我们的主要功能之一，因此我们经常检查以确保我们仍然健康。我们使用Pingdom的速度测试仪来自动测试各个页面并向我们发送每周结果；如果出现问题或变得健忘，这会提醒我们。
使用工具并获得外部帮助
我们已经使用Lighthouse，WebPagetest和Google的PageSpeed Insights来更好地了解我们可以做些什么来改善我们的网站。我们建议您找到一个基准，设定目标并进行优化，直到达到目标为止。
在Smashing Magazine上查看一些表演文章。也有很多关于该主题的精彩视频和书籍。不要害羞地聘请专家进行审核或给您建议。这个主题确实很棘手，需要很多专业知识。
太快会成问题吗？
上线不久后，我们意识到我们最大的挑战之一就是找到有空的游览。在像冰岛这样相对较小的市场中，旅游业每年以超过20％的速度增长，因此越来越难以找到离境较近的可用座位，尤其是在人气较高的旅游中。我们不是元搜索引擎，我们直接在库存解决方案之上进行集成。我们处理从搜索到预订的整个生命周期。因此，我们不必通过关联密钥将客户转移到另一个销售平台，而是可以通过购买渠道来跟踪客户，从而确保优化每个步骤。
我们需要找到一种方法来映射市场中可用的活动，因此我们使用相对数据点（例如位置，活动类型，价格，持续时间，出发时间，车辆类型和景点）构建了搜索引擎。一旦您开始研究挑战并将预订截止时间和可用性纳入考虑范围，数据集的大小就会开始迅速增长。
一年365天，一日三班的旅行包含多个方面，这将需要一千多行复杂数据。将其乘以一千次游览，您将获得一百万行以上的数据。
拥有如此众多的产品库存，但搜索面如此之多（我们使用一百多个数据点进行分类），我们需要找到一种解决方案，该解决方案不仅满足我们对速度的需求，而且具有灵活性和可扩展性足以在几毫秒内处理多达一百万条记录的处理负载。
我们考虑过要构建自己的搜索引擎，并制作了一些原型，但随后我们遇到了阿尔戈利亚，魔术开始出现。但是，与Algolia的集成非常棘手，因为我们需要设计一个数据集，以容纳所有信息和构面，但每条记录的限制为10 KB（Algolia设置的限制）。我们还需要在Algolia的API之上构建自定义窗口小部件，因为我们想使用自己的设计。
在我们的数据库中，我们存储了我们从与之集成的库存解决方案中汇总的所有产品信息。这包括元数据和描述，照片，搜索方面的分类以及价格和可用性。这就要求我们建立cron作业，在一天中的特定时间间隔内向库存解决方案的API发送请求；这些请求将检查接下来几周的更新可用性，并采用最新价格。更新完成后，我们将通过其API将更改推送到Algolia，以便搜索数据集同步并显示实时可用性和价格。
集成多种库存解决方案和Algolia并非易事，但最终结果使我们感到非常自豪。搜索引擎会在25毫秒内给出响应-太快了！
来自我们的Algolia仪表板的平均响应时间
25毫秒的问题
结果集在25毫秒内立即更新，我们意识到我们需要以某种方式让用户知道发生了更改，因为结果可能会出现在折叠以下。
要解决此问题，我们使用“提交”按钮模拟了表单的提交进行了测试，但是该按钮实际上没有任何作用，因为一旦更改了任何过滤器，结果集就会更新。所有按钮的作用都像锚一样，将您导航到结果集，从而使您感觉到下面的结果集已发生更改。
我们还测试了黄色淡入淡出技术，以突出显示结果集编号中的更改，只是让人们知道发生了更改并且结果数量已更改。
最近，我们一直在尝试滑动面板，如果结果集发生更改，该面板会显示两秒钟。在移动设备上，我们固定了此预览的位置，以便人们可以立即看到他们的更改对结果产生的影响。
结果集更新时，我们会巧妙地通知用户。
微妙地通知结果集中的更改
内容仍为王
对于我们来说，内容是设计的关键部分-不仅是标签和标题，而且是我们销售产品的描述。我们经营一个市场，因此我们的供应商向我们提供他们自己的营销材料，包括文字和图像。因为我们与200个供应商合作，并且有1000多个旅行团可供销售，所以您可以想象每个项目之间的巨大差异。
这导致我们需要重写我们提供的大多数产品的说明。我们利用这个机会来增强描述，使描述更短，更直接。我们将自己放在旅行者的鞋子上，阅读并尝试理解我们出售的每种产品。什么信息是必要的，什么仅仅是浪费的绒毛？是否缺少我们可以尝试回答的关键要素，并且可以突出显示我们认为重要的关键细节。
这个过程既缓慢又重要。它仍在进行中，但是它使我们能够在我们出售的所有产品中添加个人风格和品牌。我们希望我们的语气是朋友或友善的当地人的态度，他们能为您提供诚实直接的答案，而不是美化旅行者的陷阱（可能会如此宏伟）。这使我们还可以使用稍微简单一些的语言，因为我们的许多客户都是非母语的英语使用者。在海明威的应用程序是一个伟大的工具来帮助我们改一下，形成我们的句子使它们更容易阅读和理解。
使用海明威应用程序编辑内容前后测量清晰度
使用海明威应用程序编辑内容之前和之后以测量清晰度。
消除摩擦
电子商务充满了障碍，不安全感以及复杂的形式和标签。用户通常必须注册或放弃不必要的个人信息才能完成购买。一个小错误，您就永远失去了客户。我们的处境更加困难，因为大多数客户在逗留期间仅购物一次，因此我们没有太多机会与他们建立关系。
因此，我们不需要任何人注册即可签出产品或将产品添加到他们的收藏夹列表中。我们将他们的选择存储在cookie中，但允许他们共享一个链接，以显示其已保存列表的内容。
用户无需注册或提供电子邮件地址即可共享自己喜欢的旅行的集合。
我们将相同的理念应用于结帐，没有任何隐藏费用，也不会索要我们不需要的任何信息。我们解释了为什么我们需要收集的信息；我们自动建议国家/地区电话代码；并且我们确保输入字段提供正确的键盘格式。
使使用手机输入信用卡号码更容易
对我们来说，电子商务有两个主要障碍。第一个是让访问者放弃其电子邮件地址，第二个是获取其信用卡信息。我们尝试先询问他们的信用卡，然后再询问他们的姓名，电话号码和电子邮件地址。这背后的想法是，如果他们愿意跨越提供信用卡的最大障碍，那么提供其余的信用卡就不会有问题。尽管我们没有看到转换发生重大变化，但实验还是成功的。因此，我们恢复了经典方法，因为它感觉更自然。
结论
打造出色的移动体验确实非常困难且耗时，但是只要对细节足够重视，您就可以成功。对我们来说，距离上线仅8个月，因此尽管取得了良好的进展，但我们距离目标还很遥远。
我们的目标是在六个星期内推出最低可行产品（MVP），包括设计和开发第一个版本。在第一个版本中，我们必须采取一些捷径，但是我们想证明我们能够进行转换。在上线的两天内，我们进行了首次销售，即$ 2500的雪地摩托之旅。从那以后，成千上万的旅行者使用我们的服务来预订他们的梦想假期。现在我们已经开始专注于产品的下一阶段，敬请期待。
