广东网站建设：简化移动互动

2019.08.12 mf_web

在本文中，我们将介绍如何识别用户希望在移动设备上完成的任务，尽可能多地记住用户的情况，假设用户的操作会成功（并让他们接受他们的操作）下一个任务）以及如何预测用户的下一步行动，并做好相应准备。广东网站建设

简化移动互动

对于桌面用户，我们将专注于需要花费更长时间和精力的互动。

在本文中，我们将介绍简化移动互动的四种核心方法：

确定用户希望在移动设备上完成的任务。
尽可能记住用户的情况。
假设您的用户的操作将成功，并让他们完成下一个任务。
预测用户的下一步操作，并做好相应准备。

面向任务的设计

第一件事：为什么你的用户在这里？

桌面用户可以长时间打开许多Web应用程序，以便他们所需的所有信息都在指尖。但是，当需要完成任务时，偶尔会使用移动设备。用户可能正在检查Twitter，因为他们很无聊并且想要阅读朋友发布的文章。也许他们正在检查航班，向朋友发送晚餐计划或查看公交时刻表。他们有一项他们想要完成的任务，当他们完成后，他们的手机将会放回口袋里。

进一步阅读 SmashingMag：

移动优先还不够好
网页设计中的惊喜因素
Thumb Zone：为移动用户设计
如何毒害移动用户

假设您负责Mobile Air的移动体验。在桌面上，Mobile Air的主页全部是关于销售的。票价折扣广告，诱人的目的地和旅行计划是最重要的。在拐角处可以选择查看航班，查看航班状态和查看奖励计划。

对于桌面用户，我们将专注于需要花费更长时间和精力（预订航班）的互动，因为与移动用户相比，桌面用户愿意花更多时间在网页上并且不太可能离开，而移动用户我们希望完成一项更短的任务，他们不会有太多的耐心。此外，由于在机场检查手机上的航班状态是一个常见的用例，我们将把它带到最前沿。 Mobile Air移动网站的访客不在家。最突出和最容易获得的任务应该是航班状态和登机手续。

如果你在家并希望访问Mobile Air，如果咖啡桌上放着一台非常好的笔记本电脑，你就不会从口袋里取出手机。Mobile Air移动网站的访客不在家。可能性是，他们现在正在旅行。最突出和最容易获得的任务应该是航班状态和登机手续。保留应该是可能的，但它们并不是优先考虑的事项。我们已经将整个体验放在首位，因为我们更了解用户的原因。

记忆

一旦用户访问我们的网站并登记了航班，我们就会对他们了解更多。我们知道他们有一个航班即将开始。此外，我们知道他们是谁，我们可能在我们的数据库中有更多信息，例如过去和未来的航班。使用此信息，让我们通过预测他们的行为来为他们自定义主页。

假设我们知道Ann已经检查了她的航班明天从纽约市（纽约市）到旧金山（SFO）。我们也知道她几天后从SFO返回纽约市; 两个星期后，她正在前往巴哈马群岛。这是我们如何显示她的主页：

我们知道客户正从旧金山证券交易所返回纽约并前往巴哈马群岛。这是我们如何显示她的主页。

那么，我们应该如何存储这些数据？我们可以将它存储在数据库中的服务器上，然后在客户端上使用cookie。这是存储此类事物的常用方法。然而，这实际上是一个仅限移动设备的界面，而且它将是短暂的; 一旦用户完成了他们的航班，他们将不再需要这个界面。此外，将数据存储在服务器上意味着如果Wi-Fi丢失将无法使用（例如，当Ann在船上并且她的手机处于飞行模式时）。这是使用HTML5 localStorage的航班信息缓存的实现：

// After we fetch from the server, store it:localStorage.setItem("flights", JSON.stringify([
  { from: "NYC", to: "SFO", at: "Sun Jan 1 2012 07:45:00" },
  { from: "SFO", to: "NYC", at: "Tue Jan 3 2012 16:00:00" }]));// When we first open the page but before fetching from server, retrieve the data:flights = localStorage.getItem("flights")if (flights) {
  flights = JSON.parse(flights);
  restoreFlights(flights);}

复制

这将在手机上存储航班信息，但Ann仍然无法在没有Wi-Fi的情况下打开应用程序。这就是HTML5应用程序缓存清单的用途。缓存清单告诉手机要下载哪些文件并离线使用。当手机重新上网时，它会更新这些文件。下面是我们的应用程序的简单缓存。

首先，将清单添加到html标记：

<html manifest="/application.manifest">

复制

接下来，添加清单：

CACHE MANIFEST
  # 2013-02-14
  # v1
  # Primary assets
  /favicon.ico
  index.html
  application.css
  application.js
  images/mobile-air.jpg
  NETWORK:
  /api

复制

此清单告诉浏览器缓存我们的核心应用程序资产，但要求网络用于所有API方法。这样，我们的API数据将不会被缓存。请注意，在顶部我们有一个时间戳和版本号。对清单的任何更改都将触发缓存更新; 因此，每当您发布新版本时，只需相应地更新时间戳和/或版本，下次用户在线时，他们将获得一个新版本。

此时，您可能想知道浏览器对这些新功能的支持。由于移动设备的所有限制，HTML5支持是一个受欢迎的缓解。Android 2.1+和iOS 3.2+提供HTML5 localStorage和离线支持。iOS 3.2+占 Apple移动设备的97％左右，Android 2.1+占 Android设备的99％左右。添加对localStorage的检查将是负责的，以便我们的应用程序在不可用时不会崩溃; 但我们不必添加清单检查，因为我们没有使用任何JavaScript来访问该功能 - 浏览器会自动选择它。

路由

此时，我们有一个可以脱机工作的快速应用程序，但我们还没有解决刷新时或用户退出并重新打开浏览器时的行为方式。假设安正在检查她的航班的状态并且不断刷新。我们可以提供一个按钮来执行此操作，但是如果她睡觉她的手机然后将其从口袋中拉出来怎么办？浏览器会在一段时间后（或在切换应用程序后）破坏页面的状态，因此您的应用程序需要能够恢复。这就是路线进来的地方。

任何一个独立的页面都应该有自己的路径，它应该能够通过打开该路径纯粹加载 - 这意味着我们必须能够重建我们的应用程序的状态，而不必强迫Ann从主页面开始，然后导航回到她在哪里为此，我们需要一台路由器。您可以自己构建一个，但许多优秀的JavaScript路由器可用于不同的框架。这是Backbone.js中的路由器：

// Define the routervar MobileAirRouter = Backbone.Router.extend({
  routes: {
    "": "dashboard",
    "flights/:id": "flight"
  },
  dashboard: function() {
    // Display the main dashboard
  },
  flight: function(id) {
    // Fetch flight with ID: id
    // Display flight info
  }});// Instantiate itvar router = new MobileAirRouter();// Start Backbone's history trackingBackbone.history.start()// That will trigger whichever route matches the current url

复制

结合路由器与localStorage的备份缓存系统，你将得到一个能恢复应用程序非常快，即使没有Wi-Fi接入。

感知速度

移动世界的真相是以桌面速度提供内容非常困难。大多数移动数据提供商都会看到大约几百毫秒的ping时间。这意味着，假设您的应用程序需要0毫秒来处理请求，并且手机需要0毫秒来处理和呈现它（是的！），您仍然会有300到500毫秒的延迟等待信号穿过网络。唯一的选择就是作弊。

Instagram因其用户体验而受到称赞，其核心策略之一是乐观地执行操作。这意味着当用户说“发布此状态更新”时，系统会立即显示“完成！”并将用户移回其时间轴，添加新照片。别介意数据还没有离开手机。实际上，在你点击OK之前，你的照片在Instagram的服务器上，并且在服务器确认之前它就在你的时间线上。感知速度的双重镜头！

让我们将这个概念应用到我们的移动预订系统中。我们将有五页：

提交机场和日期，
选择第一站，
挑选第二条腿，
工资，
得到确认。

我们的移动预订系统分为五页。

一旦Ann选择了她的机场和日期 - 但在她点击“查找航班”按钮之前 - 我们将获取第一站的信息。这样，如果她要更改这些值几次，我们可能会产生额外的数据成本，但下一页几乎会立即出现。以下是我们如何预取页面：

// Function to fetch flight legsvar fetchFlightLegs = function() {
  // Inside a closure, we keep some internal variables
  var key, deferred;
  // Return the actual fetchFlightLegs function
  return function(from, to, on, until) {
    // Make a key from the arguments, so that different
    // invocations restart the process
    var newKey = [arguments].join("-");
    // If request is not redundant, make a new request
    if (newKey !== key) {
      // Set the key
      key = newKey      // And set the deferred to the new request
      deferred = $.get("/legs", {
        from: from,
        to: to,
        on: on,
        until: until      });
    }
    // Return the deferred
    return deferred;
  }}();// Now, every time they change a field, we run:fetchFlightLegs(from, to, on, until);// Then, when they hit "next", we run it again// But this time we use the results to render the pagefetchFlightLegs(from, to, on, until).done(function() {
  // render the legs page});// If the fields haven't changed, we piggyback on the current request,// which has been in progress since they updated the fields

复制

为了不架起来的海量数据的成本，我们可能要包装我们在类似电话_.debounce从Underscore.js，这将延迟一个函数调用达到指定的毫秒数，并更新延迟，如果函数被再次调用。基本上，它允许应用程序在执行提取之前“安定下来”。

在我们的设计中，第一和第二条腿在不同的屏幕上被选中，但这并不意味着它们必须是单独的请求。我们可以修改我们的fetchFlightLegs功能，将第一个和第二个支柱合并为一个请求。因此，从第一个到第二个的过渡将是瞬时的。提交付款信息不需要提取。

当付款POST到服务器时，我们将与加载屏幕同步进行。我们不想在这一步取得成功。另外，异常快速的反应实际上让Ann感到不安！以下是我们的请求链在使用和不预取数据时的样子：

我们的请求链有和没有数据预取。