IOS-Web-设计开发高级教程-四-

布客飞龙
154 阅读1小时+

IOS Web 设计开发高级教程（四）

原文：Pro iOS Web Design and Development

协议：CC BY-NC-SA 4.0

九、原生 iOS 设计实现

“如果一切都在掌控之中……那你走得还不够快！”

-马里奥安德雷蒂

在前一章中，我们阐述了如何设置 iOS 环境的要点，在本章中，我们将看到如何在“商店”用例中实现这些相同的方面。

首先，我们看看如何使用 metatags 实现 iPhone 页面模型和 WebApp 模式。在第二部分，我们一步一步地看如何实现我们用例的类本机接口。每个新元素都使用自顶向下的方法呈现，总是显示用于实现该元素的代码。

iPhone 页面模型实现

在本书关于设计的第一部分中，我们看到由于 iPhone 的显示尺寸，iPhone 网页是基于页面模型范例构建的。除此之外，我们需要在 WebApp 中设置的第一件事是页面结构。

实现类似原生的页面结构

本章中的代码是在 iWebKit 5.04 框架之上编写的，实现了我们的“商店”用例的页面结构。对于我们的用例，我们还编写了一些定制的 HTML 和 CSS 代码。我们使用标题来标记定制的 CSS 和框架代码，使用粗体文本样式来标记相关的 HTML 代码。

`

` ` The Store (U.S.)

/* page content will be here */

`

一些 SEO 元标签故意从我们网页的<head>中消失，因为我们想继续关注本章的主题。我们将在第十章中看到如何使用 SEO 技术优化我们的代码。

单页结构是我们未来所有网页的基础。现在，我们需要继续实现我们的“商店”用例，开始添加设计元素，模拟 iPhone 的 iOS 原生外观。

iPhone 原生界面模拟

本机界面模拟从支持 apple-mobile-web-app 的元标签开始。如果没有这个标签，我们未来的所有努力都将化为乌有，因为网页将与 iPhone 的显示尺寸不匹配，并且不会处于 WebApp 模式。

`

The Store (U.S.) **** **** **
**         **
The Store
** **
**

/* page content will be here */

`
顶栏部分

在<body>部分，我们使用一个<div id="topbar">插入了类似本机的顶栏。

`… … …

**
**         **
The Store
** **
**

/* page content will be here */

… … …`

然后在清单 9–1 和 9–2 中，我们覆盖了它的一些 iWebKit CSS 框架默认规则。

清单 9–1。 iWebKit 框架顶栏部分

`/* from framework style.css stylesheet */

#topbar {

        position: relative;         left: 0;         top: 0;         width: auto;         background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#cdd5df),É  color-stop(3%, #b0bccd), color-stop(50%, #889bb3), color-stop(51%, #8195af),É  color-stop(97%, #6d84a2), to(#2d3642));         margin-bottom: 13px; }

/* for max-width: 320px */ #topbar {         height: 44px; }

/* for min-width: 321px */ #topbar {         height: 32px; }`

清单 9–2。 自定义顶栏部分

`/* from custom iphone.css stylesheet */

#topbar {         height: 44px;         background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#566E93),É  to(#314F7B)); }`

根据这些规则，我们覆盖了默认的背景渐变值，并在纵向和横向方向将顶栏高度固定为 44 像素，如图 Figure 9–1 所示。

images

图 9–1。 “商店”用例:空白页面(左)和顶栏内的页面标题(右)

页面标题元素

在顶栏中，我们使用一个<div id="title">添加了类似于本机的页面标题，并对其进行了定制。清单 9–3 到 9–6 覆盖了默认框架值中的一些其他 CSS 规则:

`… … …

     **
The Store
**

/* page content will be here */

… … …`

清单 9–3。 iWebKit 框架页面样式元素

`/* from framework style.css stylesheet */

#title {         position: absolute;         font-weight: bold;         top: 0;         left: 0;         right: 0;         padding: 0 10px;         text-align: center;         text-overflow: ellipsis;         white-space: nowrap;         overflow: hidden;         color: #FFF;         text-shadow: rgba(0,0,0,0.6) 0 -1px 0;         }`

清单 9–4。 自定义页面标题元素

`/* from custom iphone.css stylesheet */

#title {         color: #FFF;         font-family: "Lucida Grande", Helvetica;         font-size: 30px;         text-shadow: #3B4C66 0 1px 0; }`

清单 9–5。 iWebKit 框架页面样式元素

`/* from framework style.css stylesheet */

/* for max-width: 320px */ #title {         line-height: 44px;         height: 44px;         font-size: 16pt; }

/* for min-width: 321px */ #title {         line-height: 32px;         height: 32px;         font-size: 13pt; }`

清单 9–6。 自定义页面标题元素

`/* from custom iphone.css stylesheet */

#title {         color: #FFF;         font-family: "Lucida Grande", Helvetica;         font-size: 30px;         text-shadow: #3B4C66 0 1px 0; }`

注意我们在设计阶段是如何使用 Helvetica 字体而不是 Myriad Pro 的。Myriad Pro 是一种商业字体，不能免费使用。

**注意:**与 Helvetica 字体不同，Myriad Pro 不在 iOS 字体堆栈中。如果要使用这个字体，除了购买，还需要使用@font -face CSS3 属性，如第七章所示。

标题标签练习

iWebKit 5.04 框架不使用 HTML 标题标签(例如 h1、h2、…、h6)来构成标题部分。< h1 >标题标签定义了页面最重要的标题，而< h6 >标题标签定义了最不重要的标题。在本章的最后，尝试实现这些标签。

  • 使用

    标签，而不是 iWebKit 5.0.4 框架使用的标准。

  • 根据文本语义，必要时添加其他标题标签。

对“商店”用例的另一页重复相同的方法。您可以从 Apress 网站下载用例源代码。

面包屑栏

添加到页面结构的第二个设计元素是面包屑栏，使用<div id="breadcrumb">添加，如下所示:

`

The Store (U.S.)
        
The Store
**
**         ****         ****         ****         ****         **** **
**

/* other page content will be here */

`

面包屑包含三种图像:房屋图标、分隔符箭头和页面名称，如图 Figure 9–2 所示。在最后一个链接中，href属性没有任何值(" # ")，因为它引用了实际加载的页面。

images

图 9–2。 【商店】用例:面包屑栏(左)和英雄内容区(右)

breadcrumb 不是 iWebKit 框架提供的设计结构。因此，我们没有覆盖 CSS 样式表中的任何默认值；相反，我们从清单 9–7 中所示的草图发展而来。

清单 9–7。 自定义面包屑栏

`/* from custom iphone.css stylesheet */

/* from custom iphone.css stylesheet */ #breadcrumb {         background: #FFF;         border-bottom: 1px solid #676767;         font-family: "Lucida Grande", Helvetica;         font-size: 11px;         height: 16px;         margin: -13px 0px 13px;         text-align: center; }`

英雄内容区

在面包屑下面，我们有另一个由 sketch 发展而来的设计元素，即英雄内容区域。使用一个<div id="hero">元素添加英雄内容，它包含三个图像链接，如下所示:

`

The Store (U.S.) ` `
        
The Store
**
**         ****         ****         ****         ****         **** **
** **
**         ****         ****         **** **
**

/* other page content will be here */

`

“商店”用例通常有三个带有三个不同关联链接的图像，以提高用户体验水平，让他或她在站点地图中从一个点跳到另一个点有更多的选择。此外，这取决于开发人员以不同的方式处理这个机会。在清单 9–8 中，我们可以看到用于设计这个元素的 CSS 样式表。

清单 9–8。 自定义内容英雄区

`/* from custom iphone.css stylesheet */

/* from custom iphone.css stylesheet */ #hero {         border: 1px solid #676767;         border-top: none;         background: #FFF;         font-family: "Lucida Grande", Helvetica;         font-size: 12px;         height: 150px;         margin: -13px 10px 13px 10px;         padding-top: 4px;         text-align: center;         -webkit-border-bottom-left-radius: 10px;         -webkit-border-bottom-right-radius: 10px; }`

现在，我们进入网页的下半部分，专门讨论内容。在此特定页面上，内容仅由菜单表示，但在其他商店页面上，使用此部分可以添加任何种类的内容。

`

The Store (U.S.)
        
The Store
**
**         ****         ****         ****         ****         **** **
**
                          
**
**         **Browse Store**         **** **
**

/* other page content will be here */

`
菜单区

菜单区域被包裹在<div id="content">中，包含两个主要设计元素:标题和菜单，如图图 9–3 所示。

images

图 9–3。 “商店”用例:菜单标题(左)和边到边导航(右)

我们使用<div class="graytitle">插入菜单标题。该元素由 iWebKit 框架提供，并由清单 9–9 中的 CSS 规则定义样式。

清单 9–9。 菜单标题元素

`/* from framework style.css stylesheet */

.graytitle {         position: relative;         font-weight: bold;         font-size: 17px;         right: 20px;         left: 9px;         color: #4C4C4C;         text-shadow: #FFF 0 1px 0;         padding: 1px 0 3px 8px; }`

在标题下面，我们有典型的 iPhone 边缘到边缘导航包裹在<ul id="pageitem">里面。该元素也由 iWebKit 框架提供，并由清单 9–10 中的 CSS 规则定义样式:

清单 9–10。 边到边导航区

`/* from framework style.css stylesheet */

.pageitem {         -webkit-border-radius: 8px;         background-color: #FFF;         border: #878787 solid 1px;         font-size: 12pt;         overflow: hidden;         padding: 0;         position: relative;         display: block;         height: auto;         width: auto;         margin: 3px 9px 17px;         list-style: none; } .pageitem li:first-child, .pageitem li.form:first-child {         border-top: 0; } .pageitem li:first-child:hover, .pageitem li:first-child a {         -webkit-border-top-left-radius: 8px;         -webkit-border-top-right-radius: 8px; } .pageitem li:last-child:hover, .pageitem li:last-child a {         -webkit-border-bottom-left-radius: 8px;         -webkit-border-bottom-right-radius: 8px; }`

这个无序列表的列表项是单个菜单项。每个条目都是使用一个<li class="menu">添加的，并且由一个链接元素中的三个元素组成，如图 9–4 中的所示。

images

图 9–4。 【商店】用例:边到边菜单结构(左)和页脚(右)

每个链接<a>元素包含一个图像<img>，一个文本<span class="name">，以及另一个作为<span="arrow">元素背景图像插入的图像。在下文中，我们将单个菜单项代码分离出来，以便更好地理解它的结构。为了与菜单布局保持一致，每个菜单链接必须有三个相同图像宽度的图像。

`… … …

  •                                                  /* icon  */                 Shop iPhone            /* text */                                       /* arrow */         

    • … … …`

    页脚部分

    页面中的最后一个设计元素是页脚。在我们的“商店”用例中，页脚是最小的，只包含苹果标志。使用<div id="footer">添加页脚，并根据清单 9–11 中的 CSS 规则设置样式。

    清单 9–11。 页脚部分

    `/* from framework style.css stylesheet */

    #footer {         text-align: center;         position: relative;         margin: 20px 10px 0;         height: auto;         width: auto;         bottom: 10px; }`

    下面的代码展示了包括页脚在内的整个“商店”用例页面结构。

    `

                     The Store (U.S.)                                                               
            
    The Store
                                                
                              
            Browse Store         
            
    `

    总结

    在本章的第一部分，我们看到了如何使用“商店”用例实现 iPhone 页面模型范例。

    在本章的第二部分，我们在实践中看到了如何在 WebApp 中模拟本地应用接口。我们一步一步地看到了为 WebApps 的基本设计元素添加代码的整个过程。

    我们的“商店”用例的完整代码可以在 Apress 网站上获得。

    十、优化 iOS WebApps

    完美不是在没有更多可以增加的时候，而是在没有更多可以减少的时候

    -安托万·德·圣-exéry

    这一章是关于网页优化和搜索引擎优化(SEO)。首先我们讨论 iPhone 和 iPad 的兼容性，然后我们展示如何优化 WebApp 的性能。我们还建议了一些优化代码、减少 HTTP 请求和最小化 DOM 访问的规则。

    然后，我们演示如何压缩 WebApp，优化其可用性，并使其能够离线工作。最后，我们看看 WebApps 的移动 SEO 方法，首先分析搜索引擎的结构，然后探索如何实现面向搜索引擎的设计。我们也看看 Google 算法背后的原理和一些有用的移动 SEO 工具。

    iPad 和 iPhone 的兼容性

    除了 iPhone 和 iPad 用户的用户体验完全不同这一事实之外，好的优化背后的大多数概念对这两种设备来说是共同的。

    这些概念中的一些以不同的方式实现，以便优化设备的特定方面，而其他概念同样适用于提高用户体验的水平。

    性能优化

    优化我们的 WebApp 的性能不是一种我们只能在项目工作流程结束时执行的开发方法。与测试阶段一样，它在项目的整个过程中都是适用的。显然，在开发阶段的最后，我们对我们的 WebApp 应用了一些优化技术，但是为了减少错误和缩短整个开发时间，从一开始就结合一些好习惯是最有效的(见图 10–1)。

    images

    图 10–1。 在整个项目工作流程中应用优化最佳实践

    当我们优化我们的网页时，知道什么可以优化是很重要的。对于那些了解维尔弗雷多·帕累托原理的人来说，你也知道 80%的结果来自 20%的原因，这意味着如果不知道我们的优化过程的确切目标是什么，将很难获得积极的结果。

    接下来，我们将了解一些以规则形式呈现的最佳实践，以便清楚地展示适用于我们 WebApp 的性能优化流程的实用方法。

    代码优化

    代码优化是任何类型的优化技术的第一步，因为一切都基于代码——一切都编码在我们的网页中。好的代码可以节省带宽，减少渲染延迟，并随着时间的推移提高页面的可读性和可维护性。

    以下是在我们的 WebApp 中编写任何类型的代码时要记住的一些最佳实践。

    规则 1:使用网络标准投诉代码

    使用 HTML5、CSS3 和 JavaScript 兼容代码。除了干净的 HTML5 语法，这还意味着在页面的<head>部分插入我们的样式表，并且(除了到 iWebKit 框架的链接)在我们的网页底部插入 JavaScript。这是因为页面顶部的样式表大大加快了加载时间。另一方面，在网页底部插入 JavaScript，这样 JavaScript 代码就不会阻塞 HTTP 请求。这是因为当 JavaScript 正在下载时，浏览器不会启动任何其他资源下载，即使该资源位于不同的主机名上。

    **注意:**此规则的一个替代方法是在页面顶部插入桌面移动重定向 JavaScript 代码。我们可以这样做，因为在这种情况下，执行脚本比呈现和加载网页更重要。

    该规则有助于解析器更快地工作，并有助于减少整体呈现延迟。

    规则 2:编写简洁的代码

    写细长的代码。删除代码中不必要或多余的部分，避免在不必要的地方使用制表符和空格。如果可以用其他技术达到同样的效果，就不要使用 CSS 表达式。CSS 规则被评估的频率超出了我们的想象，会对网页的性能产生负面影响。

    **注意:**在我们的用例中，出于说明的目的，我们覆盖了许多 CSS 规则，以便呈现原始的 iWebKit 框架和我们的用例定制代码。在实际项目中，将被覆盖的 CSS 规则的数量保持在最小。

    为注释、CSS ID 和类或 JavaScript 变量和函数选择简短且有意义的名称。如果您喜欢编写 xHTML 代码，请不要犹豫采用 xHTML5 语法，并在样式表中将 CSS 规则结合到良好的因子分解水平。使用 Gzip 压缩或缩小 HTML5、CSS 和 JavaScript 代码，但要记住在项目中存储一个用于开发目的的未压缩版本。

    这个规则减少了我们网页的总重量，默认情况下，减少了渲染和加载延迟。

    规则 3:减少 HTTP 请求

    务必时刻关注导入资源(包括图片)的数量。越多的文件导入到我们的网页，就意味着浏览器的渲染和加载延迟越长。最小化 HTTP 请求的数量加快了网页加载时间。考虑到这一点，考虑在我们的 web 页面中添加 HTTP 缓存可能是一个好主意。

    HTTP 缓存，也称为 web cache，是基于很好的原理，但由于其规范限制，在 Apple Safari 中几乎无法使用。以下列表总结了 HTTP 缓存的一些主要限制:

    • **单个资源必须小于 15kB(非压缩)**为 iPhones 设计的网页应该将每个组件的大小减少到 15kB(IOs 3 之前为 25kB)或更小，以获得最佳的缓存行为。iPhone 能够缓存 105 个 15kB 的组件。尝试再缓存一个文件会导致从缓存中删除一个现有文件。
    • 全局缓存资源必须小于 1.5MB 虽然 iPhone 能够缓存多个组件，但多个组件的最大缓存限制在 1.5MB 左右(iOS3 之前为 500kB)。缓存中可用的最大字节约为 105 * 15 = 1575kB。
    • 关闭设备电源清除 HTTP 缓存如果用户需要强制硬复位，缓存中的组件将会丢失。原因是，在 iPhone 上，Safari 从系统内存中分配内存来创建缓存组件，但不会将缓存组件保存在永久存储器中。
    • 关闭标签清除 HTTP 缓存关闭除空白标签以外的所有标签，然后关闭 Safari 清除缓存。

    我们可以从开发的角度来看，这种类型的缓存是不可靠的，因为它清理得太频繁了，无法缓存现代网页中的大部分资源。即使是最压缩的 JavaScript 框架或 CSS 也很难达到 15K 以下，几乎所有网络设备中使用的图像都没有达到这一限制。HTML5 提供的离线特性对我们的目标来说是一个更好的选择，我们将在本章后面介绍它们。

    images

    图 10–2。 根据 HTTP/1.1 协议请求 WebApp 资源

    除了减少我们网页的渲染时间之外，遵循这一规则的最好理由是 HTTP/1.1 协议规定浏览器只能并行下载每个主机名的两个资源，如 Figure 10–2 所示。

    解决这种瓶颈的方法是将我们的外部资源分散到多个主机名上。最后，我们不能忘记在我们的网页中避免所有的 HTTP 重定向。HTTP 重定向是使用 301 或 302 状态代码完成的，在这两种情况下，它都会增加平均页面加载时间的延迟，从而降低用户体验的质量。

    该规则通过减少客户端和服务器端之间的通信延迟来减少加载时间。

    规则 4:结合 CSS 和 JavaScript 文件

    这个规则必须考虑到项目的复杂性，但是基本思想是我们将所有的 CSS 规则和 JavaScript 代码合并到一个文件中，而不是拥有多个文件。这将降低 HTTP 头的权重，并减少由于 TCP 启动缓慢而导致的网页中导入多个资源的延迟，如 Figure 10–3 所示。

    这种方法的一个副作用是我们被迫更新更大的文件，即使是很小的代码更新；然而，这往往是一条正面效应大于负面效应的道路。

    images

    图 10–3。 传输延迟时间:单个和多个 JavaScript 文件的比较

    在我们的“商店”用例中，iWebKit JavaScript 框架核心和 CSS 都在单个。js 和。用优化程序缩小的 css 文件。我们可以在这些文件的开发版本(非精简版)中保留代码的逻辑结构，并随后添加头文件和单个注释，以使代码维护及其功能更新更容易。在本章末尾的参考资料部分，你会找到一些在线的迷你资源。

    规则 5:最小化 DOM

    在我们的项目中，艰苦的工作由框架完成，但是我们仍然需要编写 JavaScript 代码来完成一些项目需求。在这种情况下，规则很简单:最小化 DOM 访问和 DOM 对象的数量。

    该规则将减少网页每次运行 JavaScript 时的网页加载时间和用户体验延迟。

    图像优化

    优化阶段的一个重要步骤是图像优化。图像优化是另一个不包含任何大秘密的好习惯的例子。简而言之，优化我们的 WebApp 的图像可以显著提高我们的网页的性能，使它们更轻，并减少加载延迟。

    以下是我们处理 WebApp 图片时需要记住的一些最佳实践。

    规则 6:优化颜色深度

    在我们设计了一个图像之后，我们需要通过使用正确的图像格式导出它来优化它的权重。如果是照片，我们需要在 JPG 格式中使用一个好的压缩比。如果是用户界面图像，检查使用的颜色数量是很重要的。如果我们使用的颜色少于 256 色，我们可以将其导出为 PNG8。在大多数情况下，以 PNG8 格式导出比以 256 色 GIF 格式导出渲染的图像要小。使用相似的颜色也有助于降低颜色数量和图像权重。

    我们还应该强调，使用 Adobe Photoshop、Fireworks 或 Gimp 等图形程序导出图像会添加不需要的元数据，从而增加图像权重。通过访问元数据面板并浏览文件 images 文件信息 (T)或使用images F，我们可以在 Fireworks 中看到应用于图像的元数据

    一个解决办法是使用 PNGOut 这样的程序优化我们的图像，使它们尽可能的苗条。

    该规则减少了网页加载时间，提高了用户体验水平。

    规则 7:使用 CSS 精灵

    “雪碧”这个词可能会让你想起 80 年代，那时人们整天玩“准将 64”或“ZX 频谱”游戏。因为在计算机科学中，所有旧的东西迟早会再次变成新的，所以 web 开发人员采用了旧的精灵管理背后的思想，并把它带到了 CSS 世界。请看下面的图(10–4)中的例子。

    images

    **图 10–4。**iWebKit 框架中用于设计复选框的 CSS Sprite 技术

    要使用 CSS Sprite 技术，首先我们将两个或多个图像组合成一个背景图像，然后我们通过 CSS 设置单个图像的宽度和高度，最后我们使用 CSS 边距规则调整背景位置，以便只显示必要的部分。通过这种方法，我们可以使用一个单一的背景图像并显示几个不同的图形(单一图像)，从而节省服务器请求并加快页面加载时间。

    `/* from framework style.css stylesheet */ input[type="checkbox"] {   width: 94px;   height: 27px;   background: url('../img/checkbox.png');   -webkit-appearance: none;   border: 0;   float: right;   margin: 8px 4px 0 0; }

    input[type="checkbox"]:checked {   background-position: 0 27px; }`

    CSS 背景规则显示从坐标 0px，0px；这保证了如果我们设置 27px 的高度，默认情况下将显示关闭状态。在这种情况下，Sprite 技术通过使用 27px 的偏移量来显示 ON 状态，如第二个 CSS 规则所示。

    如果我们在用户界面中使用许多图像，CSS Sprite 技术可以帮助减少网页的全局加载时间，并避免传统翻转技术中典型的白色闪光。因为图像加载时间比呈现时间长，所以每次浏览器第一次加载翻转图像时，使用传统的图像翻转技术都会产生白色闪光。

    雪碧锻炼

    在我们的“商店”用例中，我们使用一些图片来设计面包屑栏。实现精灵技术，以加快渲染时间。

    • 对所有面包屑图像使用 Sprite。
    • 将两个或多个 Sprite 面包屑图像分组，并比较单个 Sprite 方法的渲染时间。

    比较结果，确定哪种方法最适合我们的特定用例。

    该规则减少了网页加载时间，并且每次网页运行 JavaScript 时用户体验都会延迟。

    规则 8:使用 CSS 规则代替图片

    这条规则听起来可能很奇怪，但是因为图像优化过程旨在全局减少图像的权重，所以尽可能使用 CSS 规则来代替位图图像。

    CSS 文本练习

    在我们的“商店”用例中，我们使用少量图像设计面包屑栏。实现 CSS 技术来加速渲染时间。

    • 对所有的面包屑链接使用文本而不是图像。
    • 将房屋图标与面包屑文本对齐。

    比较 Sprite 和 CSS 方法的渲染时间。

    我们需要对用户界面中涉及的所有内容使用 CSS 规则，并且只在极少数情况下插入图像。如果我们必须为用户界面元素使用一个图像，它必须优化它的颜色深度。如果我们需要插入许多图像，我们需要将这些图像插入 CSS 精灵。我们也应该对每个小的设计细节使用 CSS 规则，比如边框、背景或者渐变。

    该规则减少了网页每次运行 JavaScript 时的网页加载时间和用户体验延迟。

    规则 9:永远不要缩放图像

    根据设备视窗或设计元素的宽度和高度，始终使用具有适当尺寸的图像。依靠 Safari 缩放图像以达到最佳效果从来都不是一个好主意。该规则的唯一例外是当我们想要在单个设备 WebApp 中插入图像时(仅适用于 iPhone 或 iPad)。在这种情况下，插入宽度值为 100%的图像将适合横向(较大)和纵向(较小)方向。

    该规则减少了网页每次运行 JavaScript 时的网页加载时间和用户体验延迟。虽然遵循这条规则很重要，但请记住，指定图像的宽度和高度也很重要，因为这也有助于减少渲染时间。

    图像优化练习

    我们的“商店”用例中使用的所有图像都是 PNG 格式。尝试确定何时可以使用另一种格式(如 JPG 或 GIF)来优化这些图像。不要忘记一些格式不支持 Alpha 透明度。

    选择一个图形程序，打开位于“/images”目录和“/pics”目录下的“商店”用例中使用的一些图像。

    • 使用不同的格式导出图像。
    • 使用不同设置的相同格式导出图像。

    比较图像重量和图像质量，然后看看是否可以用优化的图像替换其中的一些图像。

    应用压缩

    Safari 支持 GZIP 压缩(RFC 1952)，因此压缩我们 WebApp 的一些资源通常是一个好主意，因为这将提高用户体验的水平。我们可以决定何时压缩 HTML5 文档、CSS3 样式表或 JavaScript 代码，而我们不想压缩图像或 PDF 文件，因为它们已经被压缩了。压缩图像或 PDF 文件会增加 CPU 开销，并可能增加文件大小。

    从服务器端来看，为了在我们的 WebApp 中使用 GZIP 压缩的资源，服务器必须配置为在请求时提供压缩的资源。另一方面，客户端必须能够支持这种类型的文件。

    图 10–4 中的请求/响应过程可通过以下三个步骤恢复:

    • Client

      连接到服务器

      向 GZIP 支持发送请求:“接受-编码:gzip”

    • Server

      感谢 GZIP 的支持

      用 Gzip 算法压缩资源

      发送 GZIP 编码的资源:“内容编码:gzip”

    • Client

      接收 GZIP 编码资源

      解压缩 GZIP 编码资源

      显示(或使用)资源

    images

    **图 10–5。**GZIP 压缩资源请求:HTTP/1.1 协议在起作用

    以下代码是 GZIP 资源的 HTTP/1.1 请求和响应的报头示例(也显示在 Figure 10–5 中)。

    GET / HTTP/1.1 ... ... ... **Accept-Encoding: gzip** ... ... ...

    服务器收到客户端请求后，确定所请求的资源是否有压缩版本。如果是，服务器将它发送给客户机，并在响应中添加以下字符串。

    HTTP/1.1 200 OK ... ... ... **Content-Encoding: gzip** ... ... ...

    我们可以使用 GZIP 压缩的文件没有限制，这是最简单的方法来实现网页重量的显著减少。GZIP 压缩可以减少大约 70%的重量。

    尽管如此，因为完美在这个世界上不存在，一般来说 GZIP 压缩有一些负面影响。

    • 首先，我们需要一个支持 GZIP 压缩的浏览器。在我们的上下文中，这不是问题，因为基于 Safari 和 WebKit 的浏览器支持 GZip。
    • 第二，如前所述，我们不能压缩图像或 PDF 文件，因为它们已经被压缩。
    • 第三，重要的是要记住，因为 Safari 需要动态解压缩这些资源，在某些情况下，这个过程会增加应用的 CPU 周期和开销，并消除可能的好处。执行测试，以确保此开销不会抵消可能获得的好处。
    可用性优化

    可用性是我们项目的基本需求，在项目流程结束之前测试可用性总是一个好主意。在项目流程的某个阶段测试我们的工作可以告诉我们是否符合项目需求，并给我们一个关于可用性的反馈。

    在第二章中，我们看到了错误可以通过项目流程传播，以及其成本如何随着传播而增加。一个好的测试阶段消除了，或者至少减轻了这个因果过程。

    images

    图 10–6。 可用性优化:在每个项目流程的阶段安排测试

    我们可以在项目流程的每一步中进行不同层次的可用性优化，我们可以在项目流程结束时，WebApp 最终发布之前再次进行可用性优化。遵循我们多样化的方法，我们可以根据项目的详细程度安排不同类型的测试。图 10–6 显示了一种方法，该方法从纸质原型测试和电子原型测试开始，并为预发布测试阶段安排了在真实移动设备上的现场测试。

    与简单的网站相比，WebApp 需要更精确的测试阶段，所以我们鼓励你永远不要忽略这个阶段。即使你从事一个简单的项目，经验也会告诉你你的项目需要测试的软硬程度。

    根据涉及的主题，我们有两种类型的可用性测试。

    • 可用性检查 通常由评估者执行，评估者不是设计者或开发者，也不参与项目。可用性检查应该从设计的早期阶段就开始。可用性检查的一个例子是认知演练，其中评估者模拟用户为特定任务解决问题的过程。
    • 可用性测试 通常由设计者或开发者对用户进行。可用性测试在设计阶段、实现阶段和发布阶段使用不同类型的测试来执行。可用性测试的一个例子是原型测试，设计师或开发者测试设计的多用户方面，包括服务和特定功能。

    认知演练是一种廉价的测试形式；然而，尽管这种方法在软件开发中比在 web 开发中更常用，但是原型测试对于我们的移动设计和开发环境来说是一个有效的选择。出于这个原因，我们在第十一章中介绍了原型测试，其中我们详细了解了如何组织、执行和评估测试。

    现在重要的是介绍可用性测试的结构以及一些更重要的概念。可用性测试和原型测试一样，由以下步骤构成:

    1. 选择测试环境。 我们需要根据我们选择执行的原型测试的类型和项目需求来选择测试环境。
    2. 创建用例。 我们需要创建一个用例，为用户定义一个任务，从项目需求中验证一个或多个用例需求。
    3. 准备测试资产。 我们需要准备和重用我们将用来执行测试的资产。
    4. 选择用户。 我们需要根据用例需求选择合适的用户。
    5. 执行测试会话。 我们需要运行测试来验证用例需求。
    6. 听取测试报告。 我们需要向用户和观察者汇报测试情况。
    7. 评估测试。 我们需要根据用例需求评估测试。
    8. 创建调查结果和建议。 我们需要提供发现和建议，推动设计师和开发人员改进项目。

    这八个步骤要求我们根据应用配置文件选择用户。然而，我们不知道需要多少用户来为测试收集可靠的数据。我们在下一节回答这个问题。

    可用性问题如何影响用户

    我们可以把问题定义为难以处理、解决或克服的事情。测试一个项目通常意味着找到能代表用户问题的东西。

    如果我们为我们的用例选择了“正确的”用户，那么即使是单一的用户测试也会给我们提供可靠的信息来改进我们的项目。然而，无论一个用户有多“正确”，他们的声音仍然是人群中的一员。用户偶然执行某个动作或受个人非代表性上下文影响的风险太高，以至于不能基于单个用户反馈创建整个测试。

    合乎逻辑的结论可能是添加尽可能多的用户来发现尽可能多的问题。虽然这种方法看起来似乎是正确的，但事实并非如此。那些有一些概率和统计知识的人知道，有一个值代表努力和结果之间的最佳比例，在这个值后面，结果与努力相比是最小的。因此，选择一大群用户并不是解决问题的最佳方法。

    最好选择一个较小的群体作为样本量，以发现尽可能多的问题。这条路把我们带到了 Jim Lewis，他在 1982 年发表了一项研究，描述了如何使用二项分布来模拟样本大小。这项研究在 1992 年得到了 Robert Virzi 的支持。Virzi 发现 80%的可用性问题是由前四到五个用户发现的，而严重的问题更有可能是由前几个用户发现的。

    images

    图 10–7。 可用性问题:不同的小组可能会发现不同类型的问题

    选择样本大小的问题似乎已经解决了，因为 4 到 5 个用户应该是我们测试会话的合适数量。甚至 20 世纪 90 年代早期的尼尔森研究也证实了这一规模。不幸的是，正如 Woolrych 和 Cockton 在 2001 年的研究中所显示的，问题并不总是影响用户。这意味着用二项式分布对问题频率的简单估计会产生误导。

    出于这个原因，我们可以为大中型项目选择的最佳方法是设置几个四至五个用户组，以代表不同类别的用户，如图图 10–7 所示，并发现尽可能多的问题。在实践中，我们需要对一个组执行测试，修复发现的问题，然后对另一个组重新执行测试。关于可用性问题的概率和统计研究是漫长而复杂的，但是通过简化结论(如图图 10–8)我们可以看到平均 18 个用户我们可以发现 85%的问题。这得到了 Jakob Nielsen 和 Thomas Landauer 在 ACM INTERCHI 会议(荷兰阿姆斯特丹)上的演讲“可用性问题发现的数学模型”的支持。

    images

    图 10–8。 可用性问题研究:我们需要 18 个用户来发现 85%的可用性问题。

    对于一个简单的项目，比如一个网站或一个不太复杂的 WebApp，我们可以依靠一个由四至五名用户组成的小组，利用我们的经验来填补剩余的空白。我们还可以通过测试前三个用户，解决问题，然后测试另外两个用户，将循环方法应用到单个组中。数据不会像多组方法那样完整，但是这种方法会更加灵活，反馈仍然有用。

    离线 WebApp

    在本书中，我们总是专注于用我们的网页来模拟本地应用环境和行为。很明显，我们的网页依赖于互联网接入来提供任何类型的服务，但它们也依赖于互联网来检索网页本身的各种设计元素。

    使用 HTML5 离线特性，我们可以通过在 WebApp 的缓存中存储任何类型的资源来解决这个问题。需要缓存的文件在一个名为清单文件的文件中声明。一旦文件被缓存，Safari 会在开始任何服务器端处理之前查找清单文件，同时避免下载之前下载和存储的文件。

    注意: Safari 会评估清单文件的内容，以确定是否要更新它。文件日期或任何其他属性将不会像我们过去在 HTTP 条件 GET 请求中看到的那样被计算。如果我们想强制更新，我们可以通过 JavaScript 来完成。

    应用缓存在浏览器会话之间持续存在，这意味着以前缓存的资源可以在没有任何网络支持或 iOS 处于飞行模式的情况下查看或继续工作。

    清单文件

    清单文件是托管在应用的 web 服务器上的一个简单的文本文件，它列出了需要由我们的 WebApp 下载和缓存的所有静态资源。清单文件由两个主要部分和一个可选部分组成:

    • 缓存清单声明
    • 缓存清单 URL 列表
    • 缓存类型声明(不需要)

    iWebKit 框架不使用任何清单文件，因为从 5.04 版本开始，它用 CSS3 方法替换了大部分用户界面图像。尽管如此，从我们的用例来看，至少缓存所有产品的图片并为用户提供离线目录访问是很重要的。

    缓存清单文件应以大写前缀“缓存清单”开头在此之下，我们可以定义三个(子)节标题，始终使用大写前缀，对应于 WebApp 要求的三种不同行为:

    • 缓存清单 这是缓存清单头。
    • 缓存 资源总是从缓存中加载，即使在联机模式下也是如此。
    • 网络 资源总是从服务器加载，即使文件列在缓存头下。这是缓存规则的一个例外。
    • 回退 资源用于替代其他加载失败或加载不完全的资源。

    如果我们在“缓存清单”声明头之后列出资源，而没有指定三种类型(子)头中的任何一种，则默认缓存类型将应用于所有列出的资源。典型的缓存清单文件类似于以下代码:

    `CACHE MANIFEST CACHE

    Comment on Cache Rule Files

    file01 file02 fileN NETORK

    Comment on Network Rule Files

    file01 file02 fileN FALLBACK

    Comment on Cache Rule Files

    file01 file02 fileN`

    在标题下方，我们还可以使用前缀“#”插入注释。此功能通常用于标记缓存版本、修改清单文件以及强制更新缓存。下面的代码显示了我们的“商店”用例的清单文件。如果我们需要缓存整个文件夹，就像在“存储”用例中一样，我们可以简单地插入绝对文件夹路径，所有文件都会默认添加到缓存清单白名单中。

    `CACHE MANIFEST

    WebApp Images inside the pic folder

    www.thestore.com/images

    WebApp Images inside the images folder

    www.thestore.com/images`

    在这段代码中，我们使用绝对路径，但是也允许使用相对路径；这完全取决于你。创建清单文件后，我们需要使用扩展名"保存它。显式”。对于“商店”用例，我们使用“cache-iphone.manifest ”,并保存在应用根目录中。

    下一步是使用属性manifest将清单文件链接到我们的 web 页面中的<html>标记内，如下面的代码所示:

    <html manifest="cache-iphone.manifest">

    清单文件必须使用“text/cache-Manifest”MIME 类型提供，因此最后一步是在。htaccess”文件，该文件放在 web 根目录中。如果没有按此顺序完成，Safari 将不会识别清单文件。

    AddType text/cache-manifest.manifest

    现在一切就绪，但是因为我们的应用查看清单文件中的资源列表以了解清单文件是否需要更新，所以如果我们想要强制执行这个更新过程，我们需要使用 JavaScript。

    **注意:**我们可以通过在文件中使用一个注释行来修改清单文件。这将在下次检查清单文件时从我们的 WebApp 生成一个更新。然而，推荐使用 JavaScript 方法，因为它为开发人员提供了更多的可能性。如果下载清单文件(其父文件或缓存清单文件中指定的资源)时出现故障，则整个下载/更新过程都会失败。

    我们可以使用window.applicationCache JavaScript 对象访问缓存，并使用update()和swapCache()方法分三步更新它:

    1. 测试(旧的)缓存是否可以更新。
    2. 更新(新的)缓存。
    3. 用更新的缓存替换旧的缓存。

    在 Table 10–1 中，我们可以看到用于缓存更新过程的三个项目。

    images

    当我们使用status属性检查applicationCache对象时，我们根据缓存状态观察到不同的返回。Table 10–2 显示了status属性返回的可能值。

    images

    现在，我们准备通过编写一条if语句来测试applicationCache对象的状态值，如果准备好了，就执行缓存更新，从而将一切付诸实践:

    if (window.applicationCache.status == window.applicationCache.UPDATEREADY) {     applicationCache.update();     applicationCache.swapCache(); }

    在工作流程的这一点上，我们的 WebApp 几乎为发布阶段做好了准备，但在我们考虑发布它之前，我们需要关注优化的另一个重要方面，一个基于我们的 WebApp 和搜索引擎之间的关系的方面。我们将在下一段中看到如何处理这一部分。

    移动搜索引擎优化

    搜索引擎优化是我们项目工作流程中的一个重要步骤。SEO 对网站来说比 WebApp 更重要，因为与网站相比，WebApp 很少依靠搜索引擎结果来推广自己。尽管如此，SEO 也应该在 WebAppdesign 的每个阶段之后。

    images

    图 10–9。 SEO 最佳实践在整个项目工作流程中的应用

    SEO 阶段提出了一些对网站和 web 应用都有价值的规则。正如我们之前看到的可访问性、可用性以及代码或图像优化，为搜索引擎优化我们的网页是一种贯穿我们项目工作流程始终的方法。制定一个完整的 SEO 计划超出了本书的范围，但是在接下来的章节中，我们看到了一些关键点，这些关键点使我们的网站排名更高，并且我们的 WebApp 对主要的搜索引擎更友好。

    剖析搜索引擎

    像谷歌这样的搜索引擎的最小用户界面背后有更多的东西。不幸的是，我们无法知道搜索引擎如何工作的每一个细节，因为这是专有信息。尽管如此，每个搜索引擎都是由几个已知的部分组成的，总的来说，这些部分可以帮助我们理解它们是如何工作的。

    • 爬虫、蜘蛛和机器人 爬虫、蜘蛛和机器人是在网络上爬行的程序，在数据库中搜索要索引的网页。Google 是基于爬虫的搜索引擎的一个例子，它的爬虫扫描网络，收集关于每个 URL 的信息。
    • 用户界面(UI) 用户界面是用户编写查询的地方。谷歌提供的最小用户界面只是每个搜索引擎前端的一个例子。
    • 搜索引擎数据库 搜索引擎数据库包含关于每个存储的 URL 的多个数据点。这些数据可以以多种不同的方式排列，每个搜索引擎都有自己的方式来完成这项工作。每个搜索引擎如何安排这些类型的数据是一个严格保守的秘密；Google 使用的 PageRank 方法就是一个例子。
    • 搜索引擎算法 搜索引擎算法是每个搜索引擎的心脏，是让一切运转的部分。该算法评估一个或多个输入(用户在搜索引擎用户界面中插入的单词)并生成输出，并搜索存储 URL 和关键字的数据库。这种算法可以归类为问题求解算法，它由分析不同网站部分的多种算法组成。每个搜索引擎都有自己的算法实现。
    • 搜索引擎结果页面(SERP) 搜索引擎结果页面，除了搜索引擎用户界面之外，是用户唯一可见的部分。这个页面是由搜索引擎算法按特定顺序分类的链接的集合。

    在接下来的部分，我们将看到如何设计和实现我们的网页，以使搜索引擎更加友好。

    面向搜索引擎的设计

    从我们项目工作流程的早期阶段开始，为搜索引擎优化我们的网页是很重要的。面向搜索引擎的设计是一个标题，代表在我们的设计阶段使用的方法。让我们来看看设计阶段的步骤。

    域名标题

    任何 SEO 方法的第一步甚至在我们打开图形程序或代码编辑器之前就已经开始了。选择错误的域名会毁了你未来在搜索引擎上获得好位置的所有努力。尽管这一步至关重要，但解决方案很简单:在域名中插入 primary 关键字。

    http://iphone.thestore.com     /* iPhone Third Level Domain Name */

    这是我们“商店”用例的假设名称的一个例子。在域名中插入主要关键字保证了我们的 WebApp 将使用一个单词进行存储，该单词将在 SEO 优化阶段的后续步骤中用作主要关键字。

    页面标题

    HTML 页面标题是需要优化的最重要的标签之一。页面标题显示为 SERP 中的第一行，它是我们 WebApp 最有意义的来源。一个好的标题是简短的，包括识别我们网页的主要关键字。

    `The Store                                                   /* Store Index Page Title */

    The Store (U.S.)                                    /* US Home Page Title */ The Store (U.S.) | Contact Us                /* Contacts Page Title */`

    我们必须为每个页面写一个独特的标题，每个标题必须包括 WebApp 的名称。代码显示了“商店”用例的三个例子。

    当标签

    曾经有一段时间，元标签是搜索引擎优化的圣杯，但现在的情况已经发生了变化，因为这种类型的标签被网站管理员滥用。要优化的一个重要标签是描述元标签。像 Google 这样的搜索引擎使用这个标签在 SERP 中的第二和第三行(如果文本足够长)显示我们的网页描述。一个好的描述标签包括我们的关键字(或多个关键字),并且信息丰富。下面的代码是“商店”用例中的一个例子。

    <meta name="description" content="Apple designs and creates iPod and iTunes,É  Mac laptop and desktop computers, the OS X operating system, and theÉ revolutionary iPhone and iPad." />        /* Store Index Page Description Metatag */

    另一个重要的元标签是关键字标签；这不是基本的，但仍然很重要。从下面的代码中我们可以看到，在我们的“商店”用例中，选择很容易，因为像苹果这样的大品牌只需要一个关键词:苹果。在其他项目中，多个关键字也可以；不要滥用就好。

    <meta name="Keywords" content="Apple" />        /* Store Index Page Keywords Metatag */

    关键词必须与潜在访问者在搜索您的网站时使用的单词和短语相匹配。

    内容

    内容对于优化我们的网页很重要。最终，用户寻找的只是一小块可以阅读的内容。重点是，现在我们需要区分用户登陆兼容页面、iPad 页面还是 iPhone 页面的情况。

    一般来说，在 SEO 内容优化中，我们需要在网页的几个战略点上使用关键字元标签中指定的关键字:

    • 页眉(主要关键字)
    • 页面标语(次要关键字)
    • 页面内容(主次关键字)
    • 页面链接(主要关键字，只要有可能)

    如果我们以面向 Google 的方式思考，在网页的上部使用我们的关键字是很重要的，因为这对爬虫来说是最重要的(有意义的)部分。因为 iPad 版本，甚至 iPhone 版本，已经严格地对内容进行了优先级排序，这使得我们的工作变得既容易又困难。

    优先内容可以使我们的工作更容易，因为我们认为这种类型的内容是基于重要的关键字和简短有意义的段落，以便以最直接和最快的方式传递信息。

    与此同时，优先化的内容会使我们的工作更加困难，因为有时内容太短，以至于几乎不可能以对人类和爬虫都有意义的方式来组织。

    images

    图 10–10。 面向搜索引擎的设计:主键“iPhone”的使用示例

    处理这种情况的方法是坚持在我们的移动版本上使用我们的优先内容，并在兼容版本的内容上多玩一点，这样我们就有更多的空间和机会来取得好的结果。

    我们需要避免的最后一件事是关键字填充的陷阱。关键词填充，简单来说就是把一个关键词用太多次或者强行放在一个段落里，唯一的目的就是增加它的使用量。如果关键词在上下文中没有意义，就不要使用。这可能会降低我们网页的质量分数。

    链接

    一个没有链接的网页就像是海洋中的一个失落的岛屿；它就在那里，但几乎没有人知道它的存在，或者，如果他们知道，如何达到它。链接的作用是连接我们的网页和其他相关信息，包括网页内部和外部的信息。链接如此重要的另一个原因是，链接对我们的 WebApp SEO 分数的最终权重有很大的价值。更准确地说，入站和出站链接有“权重”,而内部链接只是为了更好地“抓取”网站。

    谷歌及其著名的算法是由拉里·佩奇和谢尔盖·布林在 1998 年开发的，并获得了斯坦福大学的专利，是第一个为网页中的入站和出站链接分配动态和不同值的算法。谷歌网页排名算法的真正细节是未知的，因为这是该公司的秘密之一；尽管如此，一些细节是已知的。

    Google page rank 概念

    一个随机用户访问一个网页的概率称为其 PageRank 。Google PageRank 概念使用 Google 的全局链接结构来确定单个页面的价值。PageRank 给出了一个页面重要性和质量的近似值。

    实现这一概念的算法将从网页 A 到网页 B 的链接解释为网页 A 对网页 B 的投票。Google PageRank 算法不仅关注网页收到的投票或链接的数量，还分析投票的网页。由具有高 PageRank 值的网页所投的票，因为它们本身是重要的或者在网络社区中被有利地视为“已建立的公司”,权重更大，并且有助于使其他网页看起来也是已建立的。

    Google page rank 算法概念

    网页 A 的 PageRank 值给出如下:

    pr(a)=(1-d)+d(pr(t1)/c(t1)+pr(TN)/c(TN))

    这里，由出站链接给出的 PageRank 等于文档的 PageRank 分数 PR(Ti)除以出站链接的(标准化)数量 C(Ti)。

    • PR(A): 页面 A 的 PageRank 值
    • PR(T1): 指向年龄 A 的第 1 页的 PageRank 值
    • C(T1): 第一页的链接数，它指向第一页
    • PR(Tn): 一个页面 n 指向页面 A 的 PageRank 值
    • C(Tn): 页面 n 的链接数，它指向页面 A
    • d: 阻尼因子:在每一页上，一个随机的浏览者会请求另一个随机页面的概率。名义上，该值设置为 0.85，并且可以设置在 0 和 1 之间。

    让我们假设一个由四个网页组成的小宇宙，其关系如下，也如图 10–11 所示。

    • 页面 A: 不链接任何页面
    • 页面 B: 链接到页面 A 和页面 C
    • 页面 C: 链接到页面 A
    • 页面 D: 链接到页面 A、页面 B 和页面 C

    对于四个网页的总体，PageRank 的初始近似值将在这四个网页之间平均分配，并且是 0.25 (0.25 * 4 = 1)。假设每页的阻尼系数为 0.85，则提供以下等式:

    pr(a)=(1-d)+d(pr(b)/2+pr(c)/1+pr(d)/3)

    pr(a)=(0.15)+0.85(0.25/2+0.25/1+0.25/3)

    pr(a)=(0.15)+0.85(0.125+0.250+0.083)

    PR(A) = (0.15) + 0.85(0.458)

    PR(A) = (0.15) + 0.3893

    PR(A) = 0.5393

    在 Figure 10–11 中，我们可以看到使用数学符号的示例中 PageRank 值的计算。

    images

    图 10–11。 谷歌页面排名算法:网页 B、C、D 将其 page rank 值加到网页 A 上

    图 10–12 显示了相同的概念，其中网页 A 根据链接到它的每个其他网页的 Page Rank 值接收页面等级值。

    images

    图 10–12。 谷歌页面排名算法:网页 B、C、D 将其 Page Rank 值加到网页 A 上

    传入和传出链接在 WebApp 的生命中扮演着重要的角色，但链接的作用远不止链接其他网页。链接也分为内部链接和外部链接。外部链接离开网页，帮助爬虫到达你的 WebApp 的每一页。在这种情况下，外部链接扮演着与网站地图相同的角色。这就是为什么网站地图在任何 web 项目中都被强烈推荐的原因。链接到许多其他(相关)页面的面包屑也扮演着同样的角色。另一方面，内部链接不是指向不同的网页，而是指向网页本身。

    图片

    搜索引擎将网页视为文本页面，这意味着它们不理解图像。图像在我们的网站和 web 应用中有一个基本的角色，因为作为人类，我们对图像的理解要比文本好得多。因此，我们在项目中从不回避图像。

    这里的要点是，当我们需要赋予网页意义时，不要依赖图像。例如，不要在我们的图像中插入重要的文本信息，如行动号召或重要的标题。图像的作用是用一系列不同的、可能更强大的、读者可以理解的符号来支持内容。

    考虑添加文本消息作为网页中每个图像的伴侣，并添加一个alt属性来与爬虫通信。下面的代码在<div>中，它包装了我们的“商店”用例主页中的英雄内容。

    <ahref="#"><imgsrc="pics/hero_iphone4.png" alt="The New iPhone4"/></a> <ahref="#"><imgsrc="pics/hero_ipad.png" alt="The Revolutionary iPad"/></a> <ahref="#"><imgsrc="pics/hero_ipod.png" alt="The New iPod Touch"/></a>

    如果我们需要插入关于元素的额外信息，我们可以选择添加 title 属性。我们也可以选择不插入alt属性，因为图像对于爬虫和网页来说没有任何相关的意义。这方面的一个例子是下面的代码，来自边到边菜单中用作图标的图像。下面这段代码只引用了一个菜单项。

    <li class="menu"><a href="#"> <imgsrc="pics/menu_mac.png" /> <span class="name">Shop Mac</span> <span class="arrow"></span></a></li>

    该图像没有在<img>标签中指定任何alt属性。但是，如果您添加了一个带有描述的标签，就不会被认为是错误。

    <li class="menu"><a href="#"> <imgsrc="pics/menu_mac.png" alt=”Shop Mac” /> <span class="name">Shop Mac</span> <span class="arrow"></span></a></li>

    这段代码显示了对这个例子的合适描述。

    JavaScript 代码

    JavaScript 帮助我们构建一个更好的 WebApp，并模仿原生应用的外观，但这并不意味着它总是 SEO 友好的。解决方案是将我们的 JavaScript 代码外部化，就像我们对“商店”用例中使用的框架核心所做的那样。

    <scriptsrc="javascript/functions.js" type="text/javascript"></script>

    除了极少数情况，我们需要导入所有的 JavaScript 代码，无论包含在哪里，以使我们的网页更加 SEO 友好。另一方面，这会增加网页的加载延迟，但是正如我们已经确定的，完美不属于这个世界。在这些情况下，我们需要解释上下文，并根据我们的项目范围、目标和维度选择正确的方法。

    移动搜索引擎优化工具

    如今，我们有许多工具来监控我们的网页，从像谷歌分析这样的 Web 应用到一些原生的 iOS 应用。谷歌分析是一种快速简单的方法来监控流量，并清楚地了解我们的 WebApp 如何与用户互动。

    谷歌分析是由海胆在 2005 年开发的，从 2006 年开始对用户公开。使用谷歌分析工具的好处是多方面的。Google Analytics 帮助您准确地确定哪个是最有效的网页，了解浏览我们的网页所花费的平均时间，甚至了解哪个访问者成为了有效用户。这些和许多其他类型的数据被组织在易于分析的文本和图形报告中。

    谷歌分析

    注册谷歌账户后，我们可以登录位于www.google.com/analytics的谷歌分析页面。登录后，我们可以通过几个步骤从 Google Analytics 控制面板添加我们的 WebApp。

    此时，创建一个网站地图并将其添加到我们的 WebApp 中是很重要的，这样才能确保每个 URL 都能被 Google 的正常爬行过程发现。Sitemap 还可以用于向 Google 提供特定类型内容的元数据，如图像、视频、新闻等。

    Google Analytics 从我们的项目中收集数据之前的最后一步是将控制面板中的一段代码添加到我们所有的网页中，就在 head closing 标签之前。使用几个不同的仪表板视图来收集和可视化信息。我们有一个控制面板，所有信息都显示在一起，以便一次浏览所有信息，但我们也可以在单个视图中切换最小化信息。其中一些观点如下:

    • 内容概述
    • 页面视图显示
    • 访问视图
    • 跳出率视图
    • 流量来源视图
    • 引用站点视图
    • 搜索引擎视图

    重要的是要记住，数据不是实时收集的，统计数据要到每天的午夜(太平洋标准时间)才可用。谷歌分析也需要几个小时来完全更新所有的统计条目。如果我们的网页能够每月产生超过一百万的页面浏览量，提醒你除了 Google Analytics 提供的免费服务之外，还有一个更大的网站可以使用的高级版本的服务是有用的。

    关于优化和 SEO 的资源

    在 Table 10–3 中，我们使用了本章中的一些工具来优化我们的项目。如果您不熟悉这些技术中的一种或多种，我们建议您使用以下服务继续项目。

    images

    总结

    在这一章中，我们研究了最优化。在本章的开始，我们通过首先解释如何编写和生成好的图像，然后学习如何压缩我们的 WebApp，建立了处理面向性能的优化的正确方法。

    在本章的第二部分，我们讨论了可用性优化，并介绍了两种同样在 UML(统一建模语言)中标准化的方法和测试。我们还看到了问题如何真正影响我们的用户，以及如何为我们的目的选择正确的用户样本。

    本章的第三部分讨论了离线应用，我们看到了如何使用 Manifest 文件来缓存 WebApp 的单个或多个文件。

    在最后一节中，我们研究了面向搜索引擎的优化，首先介绍了移动 SEO 背后的概念，然后介绍了搜索引擎的结构。我们结束了工作，我们的网页的一部分，需要优化，使其搜索引擎友好。

    我们还介绍了著名的谷歌算法背后的概念，我们看到了像谷歌分析这样的工具如何帮助我们收集重要信息，这些信息可用于规划正确的移动战略，并在我们的 WebApp 上做出重要决策。

    十一、测试 iOS WebApps

    成为质量的衡量标准。有些人不习惯期望优秀的环境。

    —史蒂夫·乔布斯

    在上一章中了解了如何优化我们的 web 应用后，我们现在进入测试阶段。在介绍了生命周期和敏捷测试方法之后，我们将看到如何组织一个测试，首先创建一个用例，然后是测试它所需的资产。

    我们将执行一项测试，然后学习如何使用特定类型的反馈(如设计或情感反馈)和变量(如使用的触摸次数、错误次数和预计到达时间)来评估它。

    Web 开发生命周期

    在应用开发中，我们可以应用两种主要类型的生命周期:瀑布生命周期和迭代-增量生命周期。瀑布生命周期被定义为一个顺序开发模型，每个阶段都有明确定义的可交付成果。在瀑布生命周期中，从一个阶段到另一个阶段的反馈很少。

    images

    图 11–1。 瀑布式生命周期(左)和迭代-增量式生命周期(右)。

    迭代-增量生命周期是通过周期(迭代)定义的，在更小的时间部分(增量)中开发。与瀑布生命周期相比，迭代-增量生命周期在适应变更的新需求方面具有更大的灵活性。图 11–1 展示了瀑布和迭代增量生命周期之间的图形比较。在下一节中，我们将看到如何在实现阶段结束时接近测试阶段。

    Web 应用测试

    在我们简化的工作流程中，当我们退出开发阶段时，我们直接进入测试阶段。特别是在迭代的生命周期中，不同级别的测试应该出现在过程的所有阶段。正如我们现在所理解的，根据项目环境和需求，不同的项目流程可以用不同的生命周期来实现。

    我们还将了解到，每个项目阶段都至少与一个其他阶段重叠；测试阶段也是如此。

    在我们的工作流程中，如图 11–2 所示，测试阶段在实现阶段之后和发布阶段之前进行。它用于对性能、可访问性、可用性以及更一般的用户体验进行测试。

    images

    图 11–2。 项目流程:简化版本，仅在流程结束时有测试阶段。

    测试方法取决于网站或 web 应用的性质。一般来说，按照项目流程中的具体时刻，我们可以选择不同类型的测试。在下一节中，我们将看到测试的敏捷方法，这对于单个开发人员或小型开发团队来说更为舒适。

    敏捷测试

    在项目流程的第一步，我们使用线框来实现内容的早期版本。从线框来看，下一步是创建纸质原型，以更好地了解我们未来网页的内容和布局。

    纸上原型测试是第一级有用的测试，以确定我们的设计在用户体验方面是否正确。这种类型的测试是廉价的，因为它可以由单个设计者准备和执行，而不需要任何特定的工具。纸上原型测试可以识别用户界面设计和内容相关的问题。

    纸上原型测试可以很容易地确定用户在浏览过程中是否在寻找特定的按钮或试图定位自己。纸质原型测试还可以显示我们的内容是否在正确的位置，并向用户提供正确的信息。

    在进入开发阶段之前，在设计阶段进行纸上原型测试(图 11–3)。这些测试通常由设计人员执行，并且基于用于定义网站或 web 应用设计的相同草图。

    images

    图 11–3。 在流程的设计和实现阶段之间执行的纸质测试。

    敏捷测试的第二个层次是电子原型测试。这些测试是设计者在设计阶段的最后一步。因为每一步通常都与下一步略有重叠，所以这种类型的测试可以由设计人员准备，由开发人员执行。电子原型也可以由设计者和开发者准备和使用，允许设计者将工作介绍给开发者，开发者将使用电子原型作为他/她的工作的起点。

    如果电子原型在移动设备上运行，它为用户提供了几乎相同的体验，并且是可靠的。它也可以在台式机上运行，并提供良好的反馈。真实移动场景和任何其他电子原型的区别在于环境。

    images

    图 11–4。 一个真实的环境可以极大地改变用户体验(图片错过 HG)。

    在旨在评估真实移动体验的实验室测试中，环境会造成显著差异(图 11–4)。解决问题的最佳方法是对设计进行初步的纸上原型测试，对功能和服务进行电子原型测试，然后开发一个网站或 web 应用的 alpha 版本，以便在真实环境中进行测试。

    这些类型的测试实际上是免费的，因为纸质和电子原型已经作为项目工作流程的设计阶段的常规步骤而产生。

    热图测试

    另一种设置和执行起来既简单又便宜的测试是*热图伪测试。*我们使用前缀“pseudo ”,因为真正的热图测试需要眼睛追踪工具，而大多数开发团队都没有这些工具(图 11–5)。

    作为这种技术缺乏的解决办法，我们可以使用许多使用启发式算法的公司提供的在线服务(例如，Feng-GUI)来代替真实的眼球追踪。这些启发式算法通常是准确的，并且连同它们的可用性和可访问性一起，提供良好的反馈。

    通常，使用在线热图服务的流程是标准的，包括以下步骤:

    1. 注册热点图服务的帐户。
    2. 插入绝对路径或上传网页的打印屏幕。
    3. 下载图像格式的热图。

    一些服务类似于谷歌分析，并提供一个插入网页的脚本。登录我们的帐户后，我们可以查看网页统计数据和热图。这种类型的服务应该被认为是准确的，因为我们可以分析真实用户的网页。

    images

    图 11–5。 眼球追踪测试(左)和相应的热图(右)。

    我们在第四章中介绍了热图技术来分析阅读模式，以展示优秀设计的基本要素，以及什么会对用户体验产生负面影响。关键是热图可以揭示设计错误，并在设计阶段给出早期反馈。通过观察热图，我们可以确定用户的注意力是否会被一些不需要的设计元素所劫持。通过使用热点图，我们可以测试我们的设计元素层次，并检查阅读模式是否正确地遵循了内容。

    我们还应该注意到，与 9.7 英寸的 iPad 环境相比，热图测试在 iPhone 这样的小显示器环境中提供的信息较少。尽管有这个缺点，热图测试仍然提供了关于我们设计的重要信息，帮助防止设计错误在项目流程中传播。

    组织测试

    为了产生可靠的反馈，必须计划和组织每个测试的每个细节。我们选择的敏捷方法是基于*工件回收，*允许我们处理在之前的工作流程阶段使用的想法和资产。工件回收方法有助于保持准备阶段尽可能的精益。在接下来的章节中，我们将会看到如何计划和创建用例，以及如何执行测试。

    创建用例

    要记住的主要事情是，纸上原型(如图图 11–6 所示)是面向设计的，在设计测试中效果最好，这意味着它们在设计细节上提供了更可靠的反馈。电子原型也可以对设计细节给出反馈，但是因为它们在网站或应用提供的部分或全部功能和服务的特定级别上实现，所以它们主要用于收集关于功能和服务的反馈。

    images

    图 11–6。 为用例开发纸质视图(图片再发布媒体)。

    准备阶段的第一步是创建一个用例。当在网站或应用上工作时，我们可以想象一个具有特定用户动作路径的浏览会话。也许我们想测试联系页面是否容易到达，或者某个特定的服务是否有用。在这个阶段，想象力和经验是你最好的朋友。

    通常，文本用例与用例图结合使用，以便更好地理解分析阶段的项目需求。在测试阶段，这种组合仍然提供了最好的结果，因为图表可以被看作是用例的图形总结，提供了“谁做什么”和“谁与什么交互”的概念，而描述提供了对参与者(用户)和系统(用户界面、服务器等等)之间的交互所涉及的各个步骤的更好理解。

    创建文本用例

    现在我们正面临一个岔路口，因为设计师和开发人员通常拥有不同的背景知识，使用不同的工具。不是所有的设计师都知道 UML，然而几乎所有的开发人员都知道这种有用的建模语言；几乎每个面向对象的项目都使用它。

    对于那些不了解 UML 的人来说，文本用例方法提供了展示和组织测试所需的一切；熟悉 UML 提供的工具肯定会对项目流程的分析和测试阶段有所帮助。

    UML 超出了本书的范围。然而，在这一章中，我们将介绍两种表示用例的方法:文本的和视觉的。在这一节中，我们将呈现表示 UML 用例的文本方式，而在下一节中，我们将使用图表可视化地这样做。

    注: UML 代表统一建模语言，是一种用于软件工程的标准化通用建模语言。UML 包括各种类型的可视化模型，但是出于我们的目的，我们只展示其中的两种:

    • 文本用例
    • 用例图

    一本可以用简单的术语向你介绍统一建模语言提供的所有工具的简单的书是由 Mike Fowler 写的 UML 精华。

    欲了解更多信息，请访问martinfowler.com/books.html。

    当与团队一起工作时，我们通常使用文本和图形工具来表示一个用例。如果你是一个单独的设计者或开发者，你可以选择你喜欢的工具，假设你已经清楚地记住了项目的每个方面和细节。

    创建用例最简单和最直观的方式是文本方式。第一步是为您的用例编写标题，选择与用户的任务、细节层次、参与者和所使用的设备相对应的标题，它标识了上下文。“主要成功场景”是我们用例的标题。第二步是定义场景，按照一系列步骤编写我们的用例主体，其中角色(用户)执行许多动作来实现他或她的目标。每一步都代表系统(用户界面、服务器等)和参与者(用户)之间的交互。下面是一个取自我们的苹果商店用例的文本用例的例子。

    致电 Apple Store 支持部门

    **水平:**海平面(又名用户目标水平)

    行动者:用户

    设备: iPhone

    1. 用户通过选择支持链接来浏览菜单。
    2. 用户通过选择联系我们链接来浏览菜单。
    3. 用户通过选择“1-800-275-2273”链接来浏览菜单。
    4. 该设备要求确认对号码“1-800-275-2273”的呼叫
    5. 用户拨打支持电话。

    在一个用例中，有五个不同级别的细节，从上到下显示在下面的列表中:

    1. 云级别(总结目标)
    2. 风筝水平(总结目标)
    3. 海平面(用户目标高度)
    4. 鱼类水平(子功能目标)
    5. 平静级别 _ 子功能目标)

    我们可以通过设置不同的级别来处理不同级别的细节，如下例所示:

    呼叫支持

    **等级:**风筝等级

    行动者:用户

    设备: iPhone

    1. 用户转到联系人页面。
    2. 用户点击支持号码。
    3. 设备要求确认。
    4. 用户呼叫支持。

    images

    图 11–7。 用例:文本用例及其在纸上原型上的实现。

    在我们项目流程的第一阶段，称为分析，文本用例被用来识别我们项目的需求，但是它现在可以在测试阶段被重用，以比较文本用例的预期行为和原型测试的真实用户行为。我们的文本用例中的每个条目都应该与用户完成任务所执行的动作相匹配。图 11–7 展示了名为“呼叫支持”的用例

    创建用例图

    一个用例图是系统边界及其与外部世界交互的可视化表示。那些从外部世界与系统互动的人是行动者。参与者可以是用户，也可以是另一个系统。

    系统由显示系统边界的正方形或矩形表示。每一个用例都被表示为一个包含用例名称的椭圆形。演员由程式化的人类代表，其下有一个身份。

    用例图使用因子分解方法，这意味着一个用例可以包含另一个用例，如图 11–8 所示。当一个用例包含另一个用例时，一个箭头指向它，显示单词<<include>>。

    images

    图 11–8。 用例:图表和文字描述之间的比较。

    在我们的例子中，联系支持用例包括另一个用例，叫做“打电话”如果我们参考文本描述的海平面细节，联系支持用例代表点 1 和 2，而拨打电话用例代表点 3、4 和 5。在风筝级别的细节中，只有点 1 属于联系支持用例，而点 2、3 和 4 属于打电话用例。

    用例图通过组织和为每个测试提供可视化的参考，在测试阶段发挥功能性的作用。

    创建资产

    当文本用例图和用例图准备好了，我们就可以开始处理测试资产了。我们需要准备两种不同类型的资产:一种是纸质原型，另一种是电子原型。

    纸上原型

    纸质原型直接受到设计阶段使用的纸质原型的启发，甚至是从其回收的。基本上，我们需要为用例的每一步设计一个纸上原型，这意味着纸上原型和文本描述中的编号点有一一对应的关系，如图 Figure 11–9 所示。

    images

    图 11–9。 两个文本用例条目和两个纸上原型之间的一对一关系。

    每个纸上原型代表测试中特定时刻的视图，就像一帧是电影剪辑中特定时刻的视图一样。纸上原型总是使用一些颜色来减少大脑中对一张简单的纸的感知和一个完全工作的设备的真实图像之间的差距。如果您使用图形程序来选择纸张的颜色和设计，一个好的方法是使用 Pantone 颜色表，如果您使用手工方法，则使用 Pantone 笔。

    电子原型

    电子原型的设计和开发是进入实现阶段之前的最后一步。只要你没有跳过这个阶段，你就应该为测试阶段准备好一个电子原型。

    一般来说，电子原型不能提供最终版本所提供的 100%的功能；这种测试的目标是执行检查，以防止错误并避免它们在实现阶段的传播。

    然而，在 web 环境中，电子原型基于与最终版本相同的技术(HTML5、CSS3 和 JavaScript)，因此这种类型的原型通常非常接近将要发布的最终产品(如图图 11–10 所示)。

    images

    图 11–10。 文本用例(左)和 WebApp 视图(右)。

    在第二章中，我们建议使用一个框架插件来轻松开发我们项目的电子原型。无论我们选择哪种方法，概念总是相同的:创建 HTML5、CSS3 和 JavaScript 模型，以便能够测试特定的功能或特定的服务。根据电子原型提供的功能和服务的级别，我们可以执行不同级别的测试，并获得不同级别的反馈。

    执行测试

    一旦资产完成，并且假设用户准备好了，我们就可以开始执行原型测试。任何有一张桌子和两把椅子的房间都是进行纸质原型测试的理想场所。

    纸质测试和电子测试看起来不同，资产不同，测试者在测试中的角色不同，甚至反馈的等级也不同，但是这两种测试背后的思想是相同的。两者都可以归类为面向任务的测试。我们将在接下来的章节中看到同样的想法是如何驱动这些测试的。

    images

    图 11–11。 论文原型测试:论文视图与论文落地视图的关系。

    在这些测试中，纸质视图是一个实体纸质页面(一项资产)，而纸质登陆视图(另一项资产)是一个链接目标页面。“Landing”是一个相对前缀，用于增加交流的层次，更好地理解两个页面之间的上下文和关系，这在我们需要分析和讨论测试结果时很有用。

    纸上原型

    我们需要与用户一起执行的用例由一个开始用例的短语或命令来表示，并在精神上引导用户完成他的动作。参考我们的呼叫支持用例，开始测试的一个好短语或命令是通过电话联系支持。

    呼叫支持

    **水平:**海平面(又名用户目标水平)

    行动者:用户

    设备: iPhone

    **订单:**通过电话联系支持人员(针对用户)

    1. 用户通过选择支持链接来浏览菜单。
    2. 用户通过选择联系我们链接来浏览菜单。
    3. 用户通过选择“1-800-275-2273”链接来浏览菜单。
    4. 设备要求确认对“1-800-275-2273”号码的呼叫。
    5. 用户拨打支持电话。

    一旦我们向用户介绍了订单，我们就向他展示第一个和最初的纸张视图(图 11–11)，如我们之前看到的那样，由图 11–9 中的“第 01 页”表示。我们要求用户在体验过程中说出自己的想法，以及他所做的每一个动作。测试人员记录所有描述用户体验的评论。

    images

    图 11–12。 纸质原型测试:用于驱动纸质测试的文本描述。

    用户与纸张原型进行交互，而测试人员的角色是用与用户行为相关的视图替换纸张视图。在我们的示例中，如果用户触摸支持链接，测试人员会将第 01 页所代表的纸张替换为第 02 页所代表的新登录纸张视图，如图 11–13 所示。

    images

    图 11–13。 纸张原型测试:测试者改变纸张视图(图片塞缪尔·曼)。

    在最佳情况下，原型测试将在用户能够完成他的任务时结束，在最坏的情况下，当他退出时结束。在任何情况下，测试人员都必须记录用户的体验，描述用户如何完成一项任务或者为什么失败。

    电子原型

    在尽可能多地从纸上原型测试中学习之后，我们准备执行称为电子原型测试的电子变型(参见图 11–14)。测试程序保持不变；改变的是用户体验的水平和测试人员测试在纸上原型测试阶段还没有实现的功能和服务的可能性。

    电子测试可以使用台式计算机来执行，如果您使用 Fireworks 插件，就是这种情况。您通常希望使用带有移动用户代理的浏览器作为测试环境。

    images

    图 11–14。 电子原型测试:用于驱动电子测试的文本描述。

    当然，因为网站或应用通常共享用于开发电子原型的相同技术，所以这种测试的更好版本可以直接在移动设备内部运行。在这种情况下，我们可以有一个电子原型，它提供从大约 0%到大约 100%的不同级别的功能或服务。

    仅用于测试设计和反馈水平，但几乎不提供任何功能和服务的电子原型与纸质原型不可同日而语。提供大多数可用功能和服务的原型会产生与发布版本相当的反馈水平。

    在电子原型测试的桌面和移动版本中，测试人员扮演的角色与他在纸质原型测试中扮演的角色相同，只是他在测试过程中不会手动更改视图。测试人员在记录用户体验的同时，给用户分配一些要完成的任务。

    评估一项测试

    一旦所有的原型测试完成，我们需要对我们收集的数据和反馈进行工作，以评估测试和项目。重要的是要记住，测试的反馈只和测试模型一样可靠。这意味着您的原型必须尽可能地模拟或代表最终版本。

    问题是，在这种情况下，短路是显而易见的，我们需要使用看起来像最终版本的原型资产，以便获得可靠的反馈。但是，我们确实执行了原型测试，以了解如何设计最终版本和/或在实现最终版本之前验证实际设计是否正确(参见图 11–15)。底线是测试只是测试，可靠性是基于在不完整的原型上执行的测试。

    images

    图 11–15。 纸质原型测试:测试人员用来执行和评估测试的两类资产。

    这一事实在纸张原型测试中更加明显，纸张很少代表真实的用户界面，糟糕的颜色或细节以不同的方式与作为每个用户体验基础的认知感知进行交互。这些都与设计的内在层次有关——唐纳德·诺曼在情感设计中解释了设计的三个层次之一(行为和反思)。未能与设计的内在层次建立联系，会导致无法预期真实的用户体验，因为它忽略了原型在特定环境下能引起用户的效果水平或情感反应。

    **注:**唐纳德·诺曼是认知科学、设计和可用性工程领域的学者，也是尼尔森诺曼集团的联合创始人和顾问。

    欲了解更多信息，请访问www.jnd.org/books.html。

    相比之下，电子原型与最终版本共享相同的技术，因此测试和反馈会更加准确。准确性的百分比可以根据原型中实现的功能和服务的数量而变化。

    变量和反馈评估

    一般来说，一个测试可以有从非常简单到非常复杂的结构。复杂的测试会返回丰富而准确的反馈，但也需要资源和努力，这通常超出了小型开发团队的范围，更不用说单个设计师或开发人员了。

    继续使用敏捷方法，我们使用几个变量和反馈类型，以便清楚地了解我们的设计、功能和服务能在用户心目中引发什么样的体验。

    触摸次数

    要管理的第一个变量是用户完成任务所需的触摸次数。触摸次数由从内容树的起点到终点的 s 最短路径树 (SPT)定义。起点可以是我们的主页或内容树中某处的另一个页面，用于执行更具体的任务。图 11–16 显示了呼叫支持用例的必要步骤。路径看起来很简单，但是由图 11–16 表示的简化的内容树并没有表示网页之间的内部链接。

    images

    图 11–16。 用来完成呼叫支援任务的触动次数。

    SPT 算法用于其他更复杂的领域，但在我们的用例中，通过计算站点地图或内容树中完成任务所需的触摸次数，可以轻松实现相同的概念。触摸次数由测试人员在用例纸描述中报告，作为参考。

    错误数量

    第二个变量是用户在完成任务时犯的错误数量。有两类错误:

    • 触摸错误。当用户触摸错误的链接时(图 11–17 左)。
    • 触摸误识别。当用户触摸不可触摸区域时(图 11–17 右)。

    当用户触摸了错误的链接时，这意味着他或她触摸了将他或她带离终点的链接，并且该链接不属于任务的最短路径。这种类型或错误可能是用户或设计的错误。

    测试人员需要确定设计是否正确，用户是否犯了由环境或其他原因引发的错误，或者错误的设计是否引发了用户的错误。

    images

    图 11–17。 用户(触摸)错误的类型:错误链接(左)和不可触摸区域(右)。

    当用户触摸不可触摸的区域时，认为他/她触摸了链接，这是不同的。在 99%的情况下，错误是由设计错误引发的。设计错误可能意味着缺乏用户导向，或者仅仅是错误的用户界面设计。无论如何，这种类型的错误提醒我们注意一些我们在设计阶段明显忽略的细节。

    预计到达时间

    第三个变量是预计到达时间 (ETA) ( 图 11–18)，用户完成任务所需的时间。ETA 是针对知道内容树并能够通过任务的测试人员计算的。

    通常，经验丰富的测试人员会将最短路径时间作为测试的下限。下限定义了最佳值，这是一个实际上用户在测试中几乎从未匹配过的标准。用户越接近这个估计的时间，他或她就能更好地完成任务，并且(大概)用户体验的水平就越高。

    images

    图 11–18。 呼叫支持用例:计算预计到达时间(ETA)。

    ETA 在用例文件描述中报告，作为测试人员的参考。

    收集反馈

    除了这三个变量，测试人员还可以从用户的评论中收集三种类型的反馈。

    设计反馈

    第一种反馈是关于用户界面质量的设计反馈。在本书的设计部分，我们了解到，在面向触摸的世界里，设计的每一部分都是一个收集关于每个设计元素的反馈的界面。图 11–19 展示了同一个用户界面的两种不同的情感反馈。

    images

    图 11–19。 调用支持用例:同一界面两种不同的设计反馈。

    虽然这种类型的反馈在纸质原型测试中可以用来表明我们设计的正确性，但如果在电子原型测试期间收集，它会更有分量，因为实现的接口几乎与发布版本相同，并且信息包含更多有用的细节。

    期望反馈

    第二种类型的反馈是期望反馈关于用户的设计和服务期望。每当用户登陆一个不符合他期望的网页或点击一个链接，认为它代表一个与实现的服务不同的服务时，就收集这种类型的反馈。图 11–20 显示了当用户在链接后对登陆页面有不同的心理表征时会发生什么。

    images

    图 11–20。 购买 iPhone Dock 用例:期望与登陆页面中的设计不符。

    这种类型的反馈在纸质和电子原型测试中的权重几乎相同。这些测试有助于理解我们的设计、功能和服务在语义上是如何在用户的头脑中表现出来的，以及这种意义是否符合我们最初的计划。

    情感反馈

    最后一种反馈是情感反馈关于用户在测试过程中的内心感受。这种类型的反馈在电子原型测试阶段更重要，甚至在纸质原型测试阶段也不经常收集。

    情绪反馈由两种类型的刺激触发。一个是绝对的，由颜色、设计元素和所有与项目身份相关的事物触发。在图 11–21 中，iPhone 代表了这种刺激。

    另一种类型的反馈是相对，涉及环境和这种类型的刺激在用户内心世界引发的变化，如图图 11–21 所示。“环境”一词指的是属于人类用户之外的物理世界(除了移动设备)的一切。

    images

    图 11–21。 情绪反馈由两种类型的刺激触发:绝对刺激和相对刺激。

    这种类型的反馈可以在测试过程中给出关于用户内心世界的重要信息。作为来自我们网站或应用的全球交流的一部分，这种感觉非常重要。为了测试一个相对的刺激，比如环境，我们需要直接在移动设备上实现一个电子原型，并走到外面，允许用户界面加入真实世界。

    评估技术

    评估一个测试可能很困难，尤其是在处理大量数据和大范围项目时。为了获得可靠的数据，我们可以应用描述统计学的统计方法。在执行原型测试之后，我们不再需要这种类型的方法，敏捷方法仍然可以提供可靠的值，而不涉及繁重的计算和复杂的数学技巧。

    测试变量评估

    评估原型测试中涉及的变量的更简单的方法是计算每个变量的出现次数，并将其与实际测试中的出现次数进行比较。在 UML 中，用于估计(或表示)来自用例测试的期望值的实体被称为 Oracle。在我们的测试中，Oracle 由一组用自然数表示的变量值来表示。

    在我们的原型测试中，有三个自然数与三种类型的变量相关:一个是触摸次数，一个是错误次数，一个是到达时间。

    最简单的方法是为测试中必须匹配的每个变量设置一个下限。图 11–22 显示了用例文本描述中变量值的文本表示。在我们的示例中，我们将这些值设置为等于通过的测试(用户离呼叫支持链接还有四次触摸)，这意味着测试将通过或失败。

    images

    图 11–22。 一个关于变量值的文本用例。

    一旦我们为每个变量设置了最小值，我们需要为测试设置变量的模态操作符。可变模态运算符为每个变量设置一个动词，显示期望值应该如何匹配。通常，只使用少数模态运算符。我们用两个词来表达我们的目的:“必须”和“应该”

    模态运算符显示变量值是否必须匹配，或者只有应该匹配才能通过测试。我们只给出一个原型测试的简单例子:对于更复杂的项目和测试，为每个变量添加一定程度的匹配是一个好主意。

    我们的用例测试只需要执行四次触摸就可以通过，没有触摸错误。ETA 变量的“should”属性表示这个变量的值不是通过测试的“必须”条件。在某些情况下，通过包含一些已通过案例的子集，设置每个变量的匹配百分比，可以获得更可靠的结果。

    测试反馈评估

    使用变量时，最重要的是知道如何设置它们。这个难的部分做完了，剩下的就是对比数据了。这种方法技术性更强，但不需要测试人员具备大量的技能或经验。

    一个完全不同的场景是反馈评估。这是因为我们没有可以比较的数字，我们的经验将发挥重要作用。由于这个原因，我们可以引入任何实验方法或技术来评估反馈，只要我们指定了程序。

    images

    图 11–23。 带有用户反馈注释的文本用例

    收集三种类型的反馈。图 11–23 显示了我们如何记录用户反馈的例子。当一切就绪后，我们需要记住每个反馈都有分量。反馈的权重是它相对于上下文的内在价值。用户可能会报告对我们的界面感到困惑，但特定环境中的压力水平可能是认知资源减少的结果，或者这些模式可能受到另一个应用或一些环境变量的制约。因此，需要测试人员的经验和实践来从用户的反馈中收集可靠的信息。

    测试资源

    Table 11–1 提供了本章中用于测试我们项目的一些工具。

    images

    总结

    在这一章中，我们看到了计划测试阶段的重要性，以及如何在整个项目流程中执行这个阶段——而不仅仅是在过程的末尾。

    我们首先展示了热图如何成为设计师和开发人员的可靠反馈来源。然后我们引入了纸质和电子原型。我们看到了这两种类型的测试如何帮助测试人员收集不同类型的反馈。

    我们讨论了如何通过从流程流的先前步骤中应用工件回收来组织测试。我们看到了如何使用不同层次的细节来创建测试和用例。我们使用了 UML 符号，引入了用例文本描述和用例图。

    然后我们看到了如何用纸质和电子原型进行测试。我们看到了如何创建和回收资产，以及电子原型是在设计的早期阶段执行的，而电子原型是在设计阶段的末期执行的，然后才进入实现阶段。

    我们还看到了电子原型，因为它与 web 站点或应用共享相同的技术，所以可以在办公室之外的真实场景中测试项目。

    最后，我们看到了如何评估一个测试以及这个过程中涉及的变量和反馈类型。我们提出了评估中使用的三种变量(触摸次数、错误次数和预计到达时间)和三种反馈(设计、期望和情感反馈)。

    十二、最大化 iOS Web 应用的市场

    天赋赢得比赛，但团队合作和智慧赢得冠军。

    —迈克尔·乔丹

    在本章中，您将学习如何推广 WebApp。您将看到如何使用一些特定的方法来帮助保证 WebApp 具有良好的可见性，甚至在它发布到网络上之前。

    我们将讨论 Beta 测试邀请和新闻发布；您将看到为 WebApp 创建网站的好处，以及如何使用视频社交网络(如 YouTube)来提高知名度。

    我们还将向您展示如何将 WebApp 提交到苹果 WebApp 门户网站，以及除了苹果官方门户网站之外，网络还提供了哪些其他选项。最后，我们将讨论如何将你的 WebApp 货币化，以及为此你可以使用哪些服务。

    使用您的移动战略

    之前，在第二章中，我们制定了一个移动战略，并讨论了该战略对于实现目标和减少错误，最终创建一个成功的项目是多么重要。一个成功的营销计划的关键是准确地知道你的 Web 应用能提供什么，以及你的潜在用户的概况。这就是为什么在项目早期制定的移动战略在这一点上变得至关重要。

    利用开发移动战略时收集的信息，您可以针对特定范围的用户群更好地营销您的 Web 应用。第十二章介绍了一些最好的方法。

    如何推广你的 WebApp

    假设你的移动战略已经走上正轨，并且你知道你要瞄准的用户群，你就可以考虑如何推广你的 WebApp 了。正如您将在以下部分看到的，可以使用各种技术来接触更广泛的潜在用户。

    这些技术可以根据 Web 应用的开发状态而改变。在发布的早期阶段，使用测试版邀请进行测试，并向少数重要用户介绍 Web 应用。如图 Figure 12–1 所示，一旦 Web 应用准备就绪，您就可以设计一个网站来创建一个身份和/或创建一个 YouTube 频道，您可以在其中插入关于最重要功能的视频教程。

    images

    图 12–1。 一个推广 native 和 WebApps 的 Wordpress 主题(图片来源:Templatic)。

    在这一点上，Web 应用已经准备好在主要的面向苹果的博客上发布，并插入到一些主要的 WebApp 门户网站中，在那里您可以获得潜在用户的可见性。一旦 Web 应用在主要的 WebApp 门户上上线，就该利用社交网络的病毒性质来围绕您的 Web 应用进行正面宣传了。

    使用测试版邀请测试者

    营销计划的第一步甚至在 Web 应用发布之前就已经开始了。在设计人员和开发人员在内部完成 alpha 测试之后，Web 应用进入 beta 测试阶段，真实用户在他们自己的环境中测试它。

    测试邀请阶段包括一小组用户，根据他们的个人资料和与其他重要用户的潜在联系来选择。选择这类用户是因为他/她代表了测试 Web 应用的重要特征；他/她还与潜在用户有着重要的联系，而这些联系是通过其他沟通渠道无法达到的。

    在您的 Web 应用中，提前为 Beta 测试人员创建一个帐户，并在用户使用 Web 应用之前将该帐户和其他信息发送给用户，这将是一个好主意。这将为测试人员创造一个更舒适的环境，并帮助他将所有的服务和功能联系起来，减少他的学习曲线。

    测试人员的一个很好的选择可能是另一个团队的设计师或开发人员，一个参与特定业务的用户，他可以传播关于 Web 应用的消息，或者一个重要的博客作者或记者。这一策略的见证人是美国记者、《华尔街日报》的首席科技专栏作家沃尔特·s·莫斯伯格(Walter S. Mossberg)，他总是在苹果公司的最新设备实际发布到每一家苹果商店之前收到该设备的版本。事实上，莫斯伯格在等式中扮演的角色更像是一个测试版审核者，而不是测试者，但苹果战略背后的概念是相同的。

    使用新闻稿

    报刊永远是各类新闻的第一环节，数字新闻也不例外。在网上主要的面向苹果的博客上发布关于你的发布的新闻稿是很重要的。你必须确保为你的 WebApp 提供一个完整的描述和关键功能的截图，确保细节不被博主掌握。

    创建一个 WebApp 网站

    创建一个网站或 web 应用意味着在互联网上传播其身份信息，被搜索引擎索引，并代表每个潜在用户的支持点。许多设计人员和开发人员在本地和 Web 应用过程中都忽略了这一步，这是一个严重的错误。对于任何类型的应用来说，网站都是最好的沟通渠道之一。

    当设计一个网站时，记住你的 web 应用的身份和主要用户的目标轮廓是很重要的，这样你就不仅仅是在追求你个人的设计品味。在这个阶段，颜色的选择和设计中使用的线条类型至关重要。为一个主要是女性的 Web 应用创建一个激进的设计可能会在你的促销活动中对你不利。

    images

    图 12–2。 本地应用 Twitterrific 提供了一个应用网站的好例子。

    在第四章中，我们讨论了色彩心理学以及色彩和用户心情之间的关系。除了正确选择颜色和线条，网站还必须包括以下部分:

    • 功能。这就是 Web 应用能为用户做的事情，清楚而直接地陈述出来。功能也可以在主页上以预览的形式呈现，如图图 12–2 所示。
    • **版本历史。**务必注意 Web 应用中实现的所有更新和新功能，以便为开发人员提供背景知识，并为用户提供参考。
    • **教程。**重要的是，在网站上，用户能够找到一个教程，这将有助于他使用所有的主要功能和实现的服务。
    • **关于。**在可能的情况下，清楚地描述你的团队是很重要的。表扬整个团队将有助于你的应用在用户面前看起来更加专业。
    • **支持。**为用户提供支持，以解决与 Web 应用中实现的服务和功能相关的任何问题，这一点非常重要。对于任何想要创造回头客的团队来说，提供良好的支持是关键。
    • **社交分享选项。**为了让用户传播关于 Web 应用的新闻，提供一个社交分享选项是很重要的。在所有可用的选项中，Twitter 和脸书共享选项是必须的；提供脸书式的按钮也很重要。
    • **社区(可选)。**为开发者提供一个见面、分享和共同成长的地方非常重要。该选项仅适用于开发人员在不同地方工作而没有机会面对面交流的开源项目。
    • **博客(可选)。**更新 Web 应用的开发状态非常重要。一个活跃的博客给用户一个积极的形象，并作为良好的支持，帮助创造回头客。

    应用网站的最好例子来自于那些致力于本地 iOS 应用的网站，因为本地 iOS 项目背后的销售需求使得本地开发者在比较 web 开发者之前采用这种技术；Twitterrific 应用网站提供了一个很好的例子，如图图 12–2 所示。这两种开发方法的好处是一样的。

    最后，务必为 iPad 和 iPhone 用户实现添加到主屏幕功能。这被认为是在每个 WebApp 中实现的一个好的实践，原因有二。首先，并不是所有的用户都会给页面加书签，即使他们觉得这些页面很有趣；其次，当添加到主屏幕时，Web 应用被认为是本地仿真过程的最后一步。如果不能从主屏幕启动，访问类似本机的 WebApp 会大大降低用户的类似本机的体验。

    使用电子邮件营销

    创建应用推广网站后，鼓励潜在用户注册时事通讯是一个不错的主意，这些时事通讯会提供有关您的 web 应用状态的信息、介绍新功能或宣布错误修复。

    images

    图 12–3。 原生应用“我该不该买”就是电子邮件营销的好例子。

    Figure 12–3 展示了一个实现这种方法的网站，一旦 WebApp 退出 Beta 测试阶段并可供所有用户在线使用，它就会提供更新。

    创建 YouTube 视频教程

    视频教程是为 Web 应用的用户，尤其是初学者提供支持的好方法；这些教程简单直接地解释了如何正确使用应用的服务和功能。YouTube 视频可以嵌入到您的应用网站的教程部分。YouTube 频道在谷歌这样的搜索引擎中有很高的知名度。

    过去，许多大牌，如苹果，都有自己的 YouTube 频道(见图 12–4)。最近的频道功能现在允许用户定制频道样式和主题，为开发人员提供了匹配特定用户身份的机会。

    images

    图 12–4。 苹果桌面、iPad 和 iPhone 上的官方 YouTube 频道。

    开一个 YouTube 频道很容易；在 www.youtube.com 注册一个账户只需要几分钟。使用上传视频表单时，您必须记得选择正确的标题、描述和标签。良好的标题和标签是必要的，以便最大限度地提高视频在谷歌搜索引擎上被准确索引的可能性，使用户更容易浏览所有重要信息。

    每个视频下的描述由一个三行的预览加上一个显示整个描述内容的(更多信息)链接组成。在三行预览中，请确保插入描述视频内容所需的所有内容，仅在第三行后详细介绍。这保证了用户在与您的视频互动时获得最高水平的体验。

    提交至 Apple WebApp 门户网站

    对于 Web 开发者来说，苹果 WebApp 门户是最接近应用商店的东西。这个门户网站不能像使用不同渠道的应用商店那样，为提交的所有 Web 应用提供相同的可见性，但它仍然是推广任何类型的 Web 应用的最佳选择。

    正如在 App Store 的世界里，为了提交一个项目，需要向苹果注册一个开发者账户。这里的区别在于，在这种情况下，即使是免费版本也足以将 Web 应用提交到门户。

    images

    **图 12–5。**iPad(左)和 iPhone(右)上的苹果官方 WebApps 门户。

    从 Apple WebApp 门户，如图 12–5 所示，点击位于右侧边栏标题为“提交申请”的横幅您将被重定向到位于[developer.apple.com/devcenter/safari](http://developer.apple.com/devcenter/safari)/的苹果开发中心，在那里，一旦使用您的 Apple ID 登录，您将能够访问苹果 iPhone Web 应用表单。在表格的最后，可以插入 320 × 436 像素的应用截图和 128 × 128 像素的产品应用图标。

    您还可以通过更新或更改与您的 web 应用相关的任何类型的信息，从 Apple 开发中心管理您的提交。

    提交到其他 WebApp 门户

    有几个原因可以解释为什么使用 Apple Store WebApp 门户网站是任何 Web 开发人员推广其应用的最佳选择。第一，门户是官方来源，由苹果人员监管；第二，组织得很好。苹果 WebApp 门户并不是唯一的出路；推广您的 Web 应用的其他好方法也是可用的。

    OpenAppMkt，可在openappmkt.com/获得，是一个纯苹果风格的 WebApp 门户；它组织得很好，并提供了几个选项，如共享工具栏和用户评论框，这是苹果门户网站所没有的。从用户的角度来看，OpenAppMkt 需要一个免费的用户帐户，用户可以在其中插入自己的电子邮件信息，这些信息将用于将 Web 应用直接发送到开发人员的电子邮件帐户。

    images

    **图 12–6。**iPad 上的 OpenAppMkt。

    如果您想提交您的 Web 应用，您需要注册一个开发者帐户。从开发人员仪表板的侧边栏，您可以单击 Submit New App 按钮，并在表单中填写所有 Web 应用的信息。您还需要提供一个应用图标，选择正确的类别，并指定您的 Web 应用是否是为 iPhone 和/或 iPad 设计的及其价格。

    OpenAppMkt 对于 web 开发人员来说是一个很好的资源，它还以 80-20%的利率提供收入处理。这种方法类似于 App Store 使用的方法。Figure 12–6 显示开发者选项卡，您可以在其中上传您的 WebApp 信息。

    images

    **图 12–7。**OpenAppMkt 的添加到 Home 函数在起作用。

    图 12–7 显示，OpenAppMkt 已经为 iPad 和 iPhone 用户应用了将提醒“添加到主屏幕”插入 WebApp 的最佳实践，增加了类似本机的体验。

    images

    **图 12–8。**eHub 网站是一个不断更新的 Web 应用资源。

    另一个很好的 WebApp 门户是 eHub(见图 12–8)，可在 emilychang.com/ehub 获得。这个门户网站承载桌面项目和移动 Web 应用，并产生大量的互联网流量。

    利用社交网络的病毒式传播

    建立网站是 Web 应用营销计划的基本步骤；添加博客也是向用户更新错误修复和新功能的好方法。社交网络为从个人到企业的各种类型的推广提供了一个完美的平台。

    订阅社交网络让你有机会发布任何类型的更新。它甚至比博客更快，让你有机会发现和创造新的重要关系，如图 Figure 12–9 所示。在这方面，并不是所有的社交网络都是平等的；例如，像 Twitter 和 LinkedIn 这样的平台(能够在个人主页中导入推文)比脸书更加以商业为导向。然而，重要的是优化任何可用的通信渠道。

    images

    图 12–9。 社交网络互联的例子(来源:图片来自 Labrow Marketing)。

    说到一般的 WebApp 项目，第一步可能是创建一个 LinkedIn 帐户。LinkedIn(参见 Figure 12–9)是一个面向商业的社交网络平台，是与世界各地的设计师、开发人员和专业团队建立重要联系的最佳渠道。LinkedIn 个人资料是完整的，它提供了一个展示你的知识和过去经验的绝佳机会，还提供了向你的电子邮件联系人发送邀请、导入你的 Twitter 时间表和你的 SlideShare 演示文稿的能力，同时与你的许多渠道建立了强大的联系。

    第二步可能是创建一个 Twitter 账户。该帐户可以是个人的，也可以专用于 Web 应用。Twitter 是一个有创意的微博社交网络平台。这意味着，除了私人用户之外，许多专业设计人员和开发人员也使用它来分享他们项目的新闻和更新。Twitter 的帖子限制在 140 个字符以内，非常适合简短快速的项目更新。你的个人 Twitter 主页可以通过修改背景图片和主题的调色板来定制，以匹配任何个人身份。

    第三步可能是为你的 WebApp 创建一个脸书页面。在这三个网络中，脸书是最不注重商业的，因为与 Twitter，尤其是 LinkedIn 相比，出于职业目的使用脸书的人的比例是最低的。尽管如此，聪明地使用脸书可能会让你接触到新的潜在用户——那些还不是 WebApp 大用户或回头客的人。在这个阶段，记住不同的项目有不同的需求和优先级也很重要。选择合适的社交网络来接触你的目标用户。

    images

    图 12–10。 社交媒体网络上的病毒式传播(图片交集咨询)。

    将 Web 应用货币化

    Web 应用的赚钱不像原生应用那么容易，因为你不能依赖应用商店的支持。App Store 承担了销售你原生应用的责任。应用推广只是加分项；App Store 提供了几乎所有提交给它的应用的良好可视性。当有必要从一个需要从零开始推广的 Web 应用中提高收入时，音乐就会改变。

    除了 OpenAppMkt 这样的门户网站提供的机会之外，增加收入的两个最佳方式是通过 Google AdSense 和 PayPal 捐款。

    images

    **图 12–11。**iPad 上的 Google AdSense 服务注册页面。

    Google AdSense 提供了在你的内容中插入和展示定向广告并从中赚钱的机会。这项服务可以在移动和桌面平台上运行，有一个专门的网页应用部分。在 Google AdSense 上注册一个帐户后，您需要向您的 Web 应用添加一段代码，就像在 Google Analytics 中一样。Google AdSense 还提供了定制移动广告的能力，以最好地匹配您的 Web 应用设计的外观和感觉。

    PayPal 是一个众所周知的广泛使用的平台。您可以在您的 Web 应用中使用 PayPal 捐款，以便从中筹集资金。在这种情况下，将“捐赠”按钮添加到应用网站和 web 应用是一个好主意。如果你的 Web 应用是一个特定的应用，并有效地解决用户的功能或服务问题，PayPal 是一个有效的收入来源。

    WebApp 市场上的资源

    Table 12–1 列出了使用互联网推广任何类型的 WebApp 的主要 WebApp 门户和社交网络。我们已经包括了 PayPal 和 AdSense 的链接，供那些对他们的项目货币化感兴趣的人使用。

    images

    总结

    本章讨论了如何最大化 Web 应用市场，通过展示由于应用商店模式，Web 应用市场无法与本地应用市场相提并论。

    在本章的第一部分，我们介绍了在项目早期开发的移动战略如何有助于为您的项目规划促销活动和营销战略。

    在本章的第二部分，我们介绍了几种实现营销目标的方法。我们使用(VIP) Beta 测试人员来测试和推广应用，然后我们创建了一个网站来将 web 应用介绍给搜索引擎和互联网。创建网站后，我们创建了一个 YouTube 频道来推广应用，并提供视频支持以将视频教程导入到网站。

    在本章的第三部分，一旦我们的 Web 应用的主要结构建立起来，我们就把它提交给 Apple WebApp 门户以及其他门户，比如 OpenAppMkt。我们还看到了像 OpenAppMkt 这样的门户网站如何通过应用商店中的本地应用来帮助我们提高收入。

    在本章的第四部分，我们利用社交网络的病毒式传播，向 LinkedIn 和 Twitter 上特定类型的用户以及脸书上各种类型的潜在用户传播关于我们 Web 应用的信息。

    在本章的最后一部分，我们介绍了两种将 Web 应用货币化的方法。ADSense 服务可以为开发者提供不错的平均收入。我们还看到了 PayPal 服务如何更好地与解决重要问题的 Web 应用配合，并在用户中产生一种感激之情，促使他/她捐款。

    十三、超越移动网络，展望无处不在的计算

    那些疯狂到认为自己可以改变世界的人，才是真正改变世界的人。

    史蒂夫·乔布斯

    移动设备、无线和蜂窝通信的激增

    2011 年，谷歌首席执行官埃里克·施密特博士在棕榈泉举行的美国商业协会活动上发表主题演讲时，提供了一些关于移动使用的惊人预测。

    “我们谈论的一切和你将要听到的一切都在说，‘做移动业务’，”施密特宣称。“我们从内部观察图表，它的发展速度比我们所有的预测都要快。这是未来，每个人都会适应。”

    据世界上最具革命性的公司之一的首席执行官施密特称，在未来几年内，将有 15 亿至 20 亿人联网。“这是一个包含所有人的愿景。施密特继续说道:“只要你有某种移动设备，就不会因为你有多少钱而有所区别。

    与任何其他技术的预期扩张相比，这些数字似乎非常巨大，但事实是，根据 ITU(联合国国际电信机构)最近的一篇文章，移动使用的增长已经超过了谷歌首席执行官的崇高预测。“随着世界人口超过 68 亿，近三分之一的人在网上冲浪，”国际电信联盟市场信息和统计负责人 Susan Teltscher 说。就连美国总统巴拉克奥巴马(Barack Obama)也表示，他计划将无线设备的广播频谱扩大一倍，主要是为了应对不断增长的移动设备市场。

    新的和即将到来的移动视频应用将有助于弥补移动和媒体中心设备的巨大流量需求的大部分。例如，iPhone 和 iPad 上的 FaceTime 将极大地影响全球的网络功能。

    根据思科全球移动数据流量预测和最近的摩根士丹利报告，到 2015 年，地球上几乎每个人都将拥有一台移动设备，平板电脑的渗透将有助于将平均移动连接提高到每月 1.118 兆字节。增长率最高的是印度，为 158%，中东和非洲的年增长率为 129%。其次是其他国家和地区，如拉丁美洲、亚太地区、南非和墨西哥。

    虽然在不久的将来，媒体中心和台式电脑等家庭设备将留在现有网络上，随着时间的推移，这些网络将得到改善，但智能手机和平板电脑等移动设备将不得不等待迁移到即将到来的 4G 技术，他们将需要这些技术来有效地运行新的基于视频的应用。

    触摸屏和多点触控技术带来的下一代用户体验

    本节标题中的关键术语是“用户体验”多点触摸技术给每个人——私人用户和专业开发人员——带来了新的好处和机会。这种技术的影响如此之大，以至于现在我们认为它是电子史上的一次革命。Figure 13–1 展示了多点触控设备上可用的新应用环境的一些示例。

    乍一看，这场革命的基础似乎是多点触摸屏技术，但正如你在本书中所学的，一切都发生在用户的头脑中。从这个角度来看，触摸屏仅仅是一个触发器，而不是事件。事件是用户体验的改变。

    这种改进的用户体验来自新的多点触摸模式，移动用户可以通过多点触摸屏技术的发展来利用这种模式。这一进步从根本上改变了环境和用户之间的关系。这是新的多点触摸用户体验的进化链。

    images

    图 13–1。 多点触控技术设备上的新应用环境

    新技术、新可用性和新机遇

    当第一代 iPhone 在 2007 年推出时，移动社区受益于能够提供新的浏览体验的设备。在 2007 年之前，用手机或其他移动设备上网远没有今天这么愉快。因此，移动市场开始以令人难以置信的速度增长，甚至四年后，它仍在快速增长。

    2007 年，为苹果新设备开发软件的唯一方法是编写 Web 应用，但许多国家还没有为这种类型的革命做好准备。除了 HTML5 缓存功能，所有的 Web 应用在某种程度上都依赖于互联网接入，许多国家都无法提供廉价的 24/7 契约来满足用户的新需求，从而限制了设备的巨大潜力。

    2008 年，苹果发布了第一个 SDK 和第二代 iPhone。与此同时，iPhone 应用商店向成千上万新的原生应用敞开了大门。这些新的应用为旧的任务带来了新的模式，提供了新的和改进的用户体验。这些原生应用增强的可用性改变了用户习惯，创造了全新的习惯，将 iPhone 带到了以前没有蜂窝或移动设备的地方。

    这场革命已经开始，但直到 2010 年苹果推出 iPad 才告结束。以 iPhone 的 3.5 英寸小显示屏为代表的最后一个障碍终于被克服了。新的 9.7 英寸多点触摸显示屏提升了用户体验水平，为网络浏览树立了新的标准。它能够打入 iPhone 因其小显示屏而无法进入的市场。

    iPad 革命每天可见。医生、教授、律师和音乐家，以及航空公司和汽车厂等公司已经将新平板电脑融入到他们的日常活动或零售产品中，提高了他们工作和产品的质量，并创造了新的活动类型。

    新的和改进的可用性和用户体验水平使得计算机历史上第一次有可能将电子设备带给所有类别的用户，甚至是那些以前无法接触到的用户。一类是儿童。对他们来说，使用基于多点触摸的界面比使用基于鼠标的界面更自然。这使得平板电脑能够在早期用于许多类型的学校活动，在这些活动中，由于认知和后勤原因，使用 PC 是不切实际的，如图 Figure 13–2 所示。

    images

    图 13–2。

    *另一个新的类别是老年用户——以前从未使用过电脑或者很难使用电脑的人。我相信你能想出这样一个例子:一位父母在拿到 iPad 之前无法上网，但在拿到 iPad 后立即开始上网，没有任何问题。我母亲就是这样一个人。她从来不会用电脑，现在她像个极客一样上网，看 YouTube 上的新闻频道，查看天气预报，阅读当地报纸。

    然而，多点触摸革命还远未完成，为了与这场革命保持一致，当这些小型移动设备鼓励创建更大的基于触摸屏的系统时，这一过程中的下一个重大步骤将会发生，这些系统最终将进入我们的工作和家庭环境。我们已经习惯于在科幻电影和电视剧中看到的计算机饱和的未来也许并不像我们想象的那么遥远。

    多点触摸屏革命将如何改变下一代计算

    世界正处于移动网络革命的中心。在这场革命中，我们可以识别出两股截然不同的力量:智能手机和平板电脑。这个结论看似显而易见，但其含义比你想象的要深刻。

    一方面，iPhone 等移动设备改变了许多用户的生活方式，给他们带来了新的工作方式或简单地完成普通任务的方式。在任何其他设备之前，智能手机推动了我前面提到的巨大网络增长，这些设备引领了计算机历史上最激动人心的技术革命之一。

    的确，一些应用，比如 YouTube，可以在小屏幕上完美运行，比如 iPhone 的屏幕；其他应用，如网飞，在 iPad 的 9.7 英寸显示屏上看起来更好。这也将有助于视频应用的宽带需求增长。

    更大尺寸的视频并不是 iPad 这样的平板电脑的唯一重要特征。除了更大的显示屏，平板电脑还拥有触摸屏界面和便携功能。在平板电脑出现之前，唯一能够从互联网发送和接收数据的移动设备是笔记本电脑，使用笔记本电脑对用户来说是一种不同的体验。

    images

    图 13–3。 快思聪(左)和莎凡特(右)的家庭自动化应用

    这种新方法为用户带来了大量创新应用，如图 13–3 所示。许多公司开始熟悉平板电脑，以便将其功能集成到公司的项目中。开发家用产品的开发者首先意识到了让他们的产品与 iPad 兼容的可能性。媒体中心、家庭监控系统和其他类型的远程控制系统只是这种产品的几个例子，并且将来会有更多的这种产品。

    从家用到普适计算和环境智能

    家庭和房屋自动化是移动设备和用户环境之间的一种新型连接的两个方面，这种连接导致了所谓的“无处不在的计算”。普适计算到底是什么？

    1991 年，马克·魏泽在他的开创性论文“21 世纪的计算机”中指出,“最深刻的技术是那些消失的技术。他们将自己编织进日常生活的肌理中，直到与日常生活无法区分。”这是普适计算背后的核心概念。

    80 年代是微处理器的十年，以个人电脑为标志。那是我们真正制造计算机的十年。90 年代是网络和通信的十年，是人们将计算机连接在一起的十年。它以万维网为象征。2000 年代是个人电脑变成小型设备并变得便携的十年。它首先被笔记本电脑所象征，然后被智能手机所象征。现在的十年，电脑无处不在，无处不在，无处不在。世界的每一个部分都已经连接到网络上，可以通过网络进行搜索，并且可供用户使用。图 13–4 展示了一个普适计算的例子。这个项目叫做 vrFlora，在 UbiComp 大会上展示过。它显示了适合用户情况的自适应响应。

    images

    **图 13–4。**ubi comp 大会上的 vrFlora 项目(图片来源:Sejin Oh)

    当我们意识到计算机变得看不见的时候，无处不在的计算时代就到来了。在这个时代，人们不再是严格意义上的“使用者”，而是“主体”当人和计算机从单向关系转变为双向关系时，用户就成了主体。换句话说，主体被技术使用的方式和他们自己使用技术的方式一样。受试者可以走在街上，与连接到 GPS 卫星的智能手机的触摸界面进行互动；同时，他或她可以通过监控摄像头的视频接口进行观察，并通过生物识别系统的传感器接口进行监控。

    普适计算的原始实现的一个例子可以在增强现实应用中看到，这些应用可以在 iPhone 和 iPad 上运行(见图 13–5 和 13–6)。这些 AR 应用已经向用户体验的新范式迈出了第一步，但它们产生的数据流仍然只向一个方向流动:从对象到用户。

    images

    图 13–5。 一个增强现实的实现(image Earthmine)

    随着计算机变得越来越小，它们的并行处理呈指数增长，无处不在的计算将带来一种新型的环境，这种环境能够与一个主体进行双向交互，发送和检索数据，并实现所谓的“环境智能”。当万维网和它的用户(主体)之间的桥梁完成时，计算世界将进入一个新的时代。

    今天，我们可以用移动设备做很多事情，包括智能手机和平板电脑，来构建一个小小的未来。网络是“无处不在范式”中涉及的每一个设备之间的链接，这为每一个设计者和开发者带来了令人兴奋的机会，因为天空是无处不在计算的极限。

    记住，“……那些疯狂到认为自己可以改变世界的人，才是真正改变世界的人。”

    images

    图 13–6。 将一个环境中的物体转化为一个界面中的物体(图像纤维设计)。

    电信和普适计算的资源

    在下表中，我列出了一些资源，您可以从中获得更多关于电信、移动市场的实际增长以及无处不在的计算的新方面的信息。

    images

    总结

    在这一章中，你看到了移动革命的下一步是什么，以及无处不在的计算将会变成什么。这是结合新网络能力和新移动技术的下一步发展。

    首先，您看到了第一次移动革命远未结束，它仍然会导致移动市场和宽带需求的增长。

    接下来，您发现了新的触摸屏技术将如何培养新一代的可用性，以及这将如何为设计师和开发人员带来新的机遇。

    您还会读到触摸屏革命将如何改变下一代计算，以及家用和环境智能如何成为下一个进化阶段的一部分。

    最后，我分析了普适计算在过去几十年中的发展，并介绍了新的普适计算范式将如何改变用户角色的关键概念，改变用户与周围技术的交互方式，并将他或她变成一个系统。*

    avatar
    文章
    阅读
    粉丝