Westpac One 重设计 for Android

Posted 2023-04-18

参考技术A 英文版本： https://medium.com/@dingzhouli/westpac-one-redesign-for-android-fcc97a4afd8

我是去年年初开始使用Westpac的官方app，超级好用。然后到了上个月它自动更新，名字变成了高大上的Westpac One，体验却似乎没跟上。结合Play Store上的用户反馈和我这一个月每天的使用发现，真心是改得一塌糊涂。这里的一塌糊涂是指操作体验，极端之卡、毫无利用到任何手势操作、宛若给10寸大屏设计的迷你点按区域和让人咋舌的零动效过渡。根据对细节部分的探究终于搞明白。直到我拖拽了Westpac网上银行桌面网站的窗口时震惊了，也明白了。原来这APP压根就是个简单封装成应用的响应式网站！我承认Web App的牛逼，却对不过大脑的封装和低下的性能举双脚反对。

界面呢，看起来还行，加了全新的色标系统；无关痛痒的登陆页自定义背景；新的置底Tab主导航和高频出现的抽屉菜单。好像比老版本热闹了些、时尚了些。

这一部分我没做重设计，因为真的很好用~

旧版界面 | 当前界面 | 当前界面（PIN）
----|-----

许久以前，Westpac的APP还是能保存用户名的，现在沿用了绝佳的Login with PIN的功能，让用户能自行设置五位短密码登陆账户，酷炫吊炸天。不过登陆界面自定义背景图片的噱头添置是为了向某些PM示好吗？虽然我真的在三周内换了三次图片。

另一处变动是新增了一个浏览所有账号种类（比如消费账户、储蓄账户和信用卡等）的入口页面，类似大家熟悉的Six Pack导航方式。咦，这和之前的APP太不一样了，不过想想这根本就是个响应式网站我也释然了。作为支持了Westpac四年的资浅用户，我太明白不过究竟哪个设计更好了。事实上，其中只有一个账号可以进行刷卡交易和对外转账，移动端使用APP的情境更多的应该是即时查账&转账，需要每次进去看到一个纵览吗？我想答案是否定的。对于桌面版，这可能是一个可以保留的、便于实施管理的界面。

旧版主界面 | 当前主界面 | 重设主界面
----|-----

在重设中，和旧版类似，直接了当地显示了主账号记录。使用Material Design风格进行设计，滑动Tab而非置底。秉承快速浏览+转账这两个移动端核心功能，FAB此处可以帮助快速转账，而非需通过进一步的深入菜单实现。

我取消了滑稽的色标系统，这套看似直观的组织方式需要相当长时间的使用去记忆，而且似乎只是为了新的Timeline设计的。我明白Timeline对于快速整体了解Transaction有所裨益，可是它和针对每个账号的其它界面内容有太多重复性，同时用户的账号复杂性和差异化还不至需要时间轴去显示每个账号的流水。我对其存在意义表示严重怀疑。

导航决定高度，咳咳。除了刚才我们看到的置底Tab主导航，针对每个Tab都有不同的菜单可以通过右上角的汉堡键呼出。虽然每个菜单五花八门各不同，却有着一些惊人一致的功能性项目。

当前界面菜单设计| 重设全局Drawer设计|重设FAB展开
----|-----

Payee记录着你设置并保存的所有需常产生交易的第三方账号，当然了，同时你也能进行管理，比如删除或编辑。看起来很好很温暖，可是Payee的意义不在于让用户把这个应用当成过家家游戏或者社交网络，而是便捷支付。正如你看到的那样，呼出FAB可以有效地把Paybee和支付流程结合在一起，完整入口被安置在Drawer里，当然你也可以在drawer里进行针对特定Paybee的转账，这一切取决于你。

我不知道有多少用户能很快区分account transaction, timeline和payment的区别。近乎一致的内容、排版和不痛不痒的细节差异。payment记录了所有支出，无论是对外的划款还是用户同一账号内的转账，是的你没看错，这块区域负责的内容就是输出所有出账记录其实在哦看来，Timeline和payment这两块更像是程序员自作聪明的意淫和炫技（其实也没啥技术，凑数而已），而非设计师脚踏实地调研得出的产物。

Westpac的设计师可能略微高估网上银行APP的使用情境了，我们看到桌面版上的所有功能几乎原封不动地被囊括在这款APP里，虽然正如我所说，这是一个不过大脑封装成APP的响应式网站而已。例如过滤交易记录的功能，这似乎更可能与打印形成关系。另外一个例子是申请/开通（新账号、信用卡、个人贷款等），这些申请和开通需要繁琐的输入步骤，即便Westpac已经较合理地把它们组织为三到四块，体验仍然不妥。在这次重设中我依然保留了过滤记录的功能，删除了申请/开通，期望APP聚焦于浏览和快速转账。

搜索放置顶部，完全没有必要用冗长的词汇去形容搜索行为。谁都能理解网上银行的搜索功能的目标指向，至少绝不是淘宝热卖商品。所有Tab和搜索结果都可能需要的过滤功能也放在这边。

直接搜索和搜索结果过滤被我拆分成了两个步骤，搜索结果关键词高亮显示。在这里尤其要说明在当前APP的timeline部分出现的“指定账号搜索”可以丢弃了，任何搜索行为仅作用于当前Tab范围内，而非全局搜索。

之前重设过Vodafone的app，现在又是Westpac，这些都是我经常使用的应用。瑕不掩瑜，他们本身都有莫大的亮点。Westpac One的桌面版本推出也不过几个月，官方也承认有很多旧版本的主要功能没有并入，这依然是一个向前走的项目，相信它会越来越好。往往只是一个小小的改进就让我的使用体验充满了愉悦（自定义五位PIN快捷登陆），而由于我浅薄的认知，部分功能理解上的鸿沟导致了思路的出发点不同，这些重设只是我作为万千忠实用户之一，总结个人使用感受得出的一点可能不那么经得起推敲的看法。

我不明白 Westpac Payway API 和 NET 是如何工作的

【中文标题】我不明白 Westpac Payway API 和 NET 是如何工作的

【英文标题】：I don't understand how Westpac Payway API and NET works

【发布时间】：2011-02-16 15:20:11

【问题描述】：

整天在谷歌上搜索，阅读大量 PDF，但仍然对从 Westpac (a bank in Australia) 向 Payway 系统发送数据的概念感到困惑。他们通过 API 提供访问权限，但也通过他们所谓的“NET”提供访问权限。

我理解的方式是，当客户想在我的网站上付款时，如果是 NET，客户会进入页面（由银行托管或由我托管），该页面提供了输入信用卡信息详细信息的表格。然后通过正常的 POST 调用将此表单提交到 Payway 的特定 https 地址。然后处理它，浏览器返回到我指定为我在隐藏字段中发送的参数之一的 URL。

如果 API 故事类似，因此用户收到表单，填写数据，然后将数据发送到我的后端（不是 Payway 的）。然后我的后端使用提供的数据调用 payway API，一旦收到答案，就会向客户端返回确认页面。

我的理解对吗？请解释一下，因为我觉得我在这里缺少一些基本的东西。

【参考方案1】：

PayWay 的一个奇怪之处在于，虽然大多数支付网关都有 2 个选项.. 商家托管或服务器托管，但 PayWay 使用令牌请求提供了这种通过 NET 选项托管的伪商家。信用卡详细信息直接在商家网站上获取，并且只会将确认暂时重定向到服务器，然后再返回。如果付费方式帐户可与 NET 和 API 通用，这将是很棒的。但似乎 API 帐户不支持 NET 方法。所以如果你想在你的网站上接受卡片，NET 令牌方法几乎被它更大的 API 兄弟所掩盖。

【讨论】：

API 在技术上是一种更好的方法，但问题是您的服务器需要处理卡号。这意味着额外的安全工作和过度现场 (PCI-DSS)。令牌请求网络就像 API 设计的那样，浏览器直接提交给 PayWay，因此信用卡号码不会触及您的网站。

【参考方案2】：

有多种不同的方式可以与 PayWay Net 进行交互，具体取决于您想要的控制程度。最简单的方法是这样的：

您创建的 HTML 格式包含具有特定名称的字段。此表格由您的网站提供，但在提交时会转到 PayWay 网站。您可以在其中添加自己的隐藏字段和信息字段。 您的用户输入一些详细信息并单击提交。 您用户的浏览器将表单提交给 PayWay。 PayWay 验证值并显示询问信用卡信息的页面（通过 https） 用户输入信用卡详细信息，然后确认交易。 PayWay 处理信用卡交易 可选地，PayWay 可以向您的服务器发送一个指示交易状态的信息，以便您完成订单（称为服务器到服务器的付款通知） 可选，PayWay 可以将浏览器重定向回您的服务器（但不要使用它来更新 yoru 数据库）

还有一些方法可以完全自定义信用卡输入页面和收据页面。

PayWay API 不同。您在服务器上安装了一个软件。当你想进行信用卡交易时，你调用这个软件。它通过互联网与 PayWay 服务器对话，进行交易，并给您一个响应。例如，如果您正在编写电话支付系统，则可以使用它，因为 PayWay 界面中不涉及任何浏览器。

（免责声明：我为 Qvalent 工作，PayWay 的开发人员）。

【参考方案3】：

你的理解是正确的。

我已经完成了几个 Payway 集成，并且一直选择 API 解决方案，以便用户获得一致的体验并且不会在网站之间跳转。

【讨论】：

有没有办法从银行（即西太平洋银行）向网站管理员（而不是用户）发送确认电子邮件，在使用 API 时自动批准交易而不进行手动工作？