现在产品有多种形态，PC网页、PC客户端、iOS/Android端、WAP页等等。最近的工作碰到了WAP页的设计。我开始思考两个问题，第一、WAP页在整个产品多端体系中应该发挥什么样的作用？第二、基于它的使用人群规模、意欲发挥的作用，WAP页的功能模块、导航架构、交互流程、单页面布局等等该如何设计呢？
我看了很多其他产品的WAP页，也搜集了网上的相关资料，也和几位做前端开发的朋友聊了一下，现在把相关总结写出来。需要预先说明的是，这篇文章的内容并不完整，因为很多点我思考的还不太深入，另外本文也不涉及具体的设计细则。
我要说的WAP是指？
“WAP”对应着“Web”，一个偏向于移动端、一个偏向于PC端。我此处要讨论的“WAP”也有其它的称呼。从开发语言角度称为“H5”（当然“H5”这个称呼只是大家叫习惯了，其实不太严谨）。从所处位置也会和“Hybird APP”的概念有关。
WAP页存在于两个地方，浏览器内、应用内。应用内的WAP页有两个生产方：应用自身、用户制造。应用内有些WAP页可以使用浏览器打开；浏览器的WAP页可以分享到应用里，并使用应用内置浏览器打开。
WAP页解决了什么问题呢？第一、WAP页可以提供完整的产品功能，比如用Safari浏览新浪网看新闻、微信下的京东商城。第二、Android/iOS应用有的模块采用WAP页，配合应用构建完成产品功能。第三、WAP页用于宣传某项活动，WAP页真正兴盛即在于此！
WAP页设计及现状
现在看看WAP页用于提供完整产品功能时，业界采用的主流设计方案是什么。第一种，响应式设计，只一套前端样式，而根据设备类型、屏幕分辨率等自动匹配为不同的展示方式。第二种，照猫画虎，交互流程不变、页面布局不变，将Native APP用HTML+CSS（或者+js）重写一遍。第三种，依托微信服务号这样的平台，提供核心功能；这时产品的架构、导航由平台决定。
现实世界往往很复杂。比如并不是所有网站都能用采用自适应的方案。再比如相当多产品采用了第二种方案；但是所有人都知道这种方式的体验极其糟糕。WAP页访问量不大，复杂功能引导用户使用app，所以产品、设计、研发也不会投过多的精力在WAP上。第三种方案也有挑战，对于复杂产品，再遇到庞大臃肿、不聚焦、互相扯皮的团队，定位筛选核心功能并不容易。过渡依赖第三方平台，一来有风险，二来自己渐渐壮大了在第三方平台上颇受限制。
一种合理利用WAP页的方案
新用户体验产品或产品拉新时，有两种办法。一、用户要下载APP。二、服务号中提供了产品的核心功能，用户打开微信扫描二维码关注即可。毫无疑问，后者更容易开始使用。对于新用户转化为深度用户后，再下载APP使用更完整功能即可。
很多分享到SNS的WAP页也可以形成很好的二次传播，优化这部分内容并在SNS扩散传播应该可以收到不错的效果。
有些产品需要帐号体系，甚至帐户之间还会互动（具有浅社交属性）。这类产品分享到SNS、其他用户打开这些WAP页时，如果快速登录自己的帐户并形成互动呢？
综上，第一、WAP页提供产品核心功能，做精做好。第二、APP与WAP（特别是SNS平台内）互通。APP分享到SNS，SNS多次扩散传播，分享页进入后登陆帐户、账户间互动。也就是“分享-扩散-使用”整个流程的贯通。
最后的闲扯
互联网热潮非常凶猛。很多产品以为解决的需求是强需求，可以做成平台。折腾了这么多，其实做了很多没有任何价值的事情，浪费了社会资源、浪费了人力资源、浪费了钱。当然历史上也没有多少理智的事情，大家都有从众心理，谁也想借着大风做成点事情。不管怎么说Native APP设计、研发成本很高，产品初期可以用WAP页做个最小化可行产品验证一下市场需求。用户获取WAP页的成本比下载APP低很多。
随着网络状况、前端技术日臻完善，WAP页的重要性会越来越高吧。未来WAP页可以解决的事情越来越多，APP越来越少，甚至浏览器取代了应用也说不定哟。
网友评论