8
18
2022
15

我所讨厌的网页行为

有些网页的行为通常不被视为 bug,甚至是故意为之,但很令人讨厌。这里记录一些我所讨厌的网页「特性」。它们被归为两类,要么导致某些场景下用不了,或者用着很不方便,要么很打扰人。

可访问性问题

忽视系统、浏览器设置,在浏览器使用浅色主题的情况下默认使用深色主题,或者在浅色主题下代码部分使用深色主题。反过来问题不大,因为我有 DarkReader

主体文本不支持选择和复制。选择和复制之后,用户能做很多事情,比如查生字、翻译、搜索相关主题。

已访问链接与未访问链接显示没有差别。

消除可交互元素(链接、按钮)的 outline。这个 outline 以前是虚线框,现在火狐改成了蓝色框,用于标识当前键盘交互的对象。

搜索框不支持回车确认,必须换鼠标点击。

位于文本框后的按钮不支持使用 Tab 键切换过去,并且 Tab 键在此文本框中也没有任何显著的作用。必须换鼠标点击。

需要交互的元素不能被 vimium 插件识别为可点击。这大概是使用非交互元素来处理交互事件,甚至事件监听器都不在元素本身上。

使用 JavaScript 实现原本可以直接用链接实现的内容(链接目标是某个 JavaScript 函数调用)。这导致我无法使用中键来在新标签页中打开。

显著不同的内容没有独立的 URL。尤其见于一些单页应用(SPA)。要到达特定内容(比如加书签或者分享给别人),就只能记录先点哪里、再点哪里等。

预设用户的屏幕大小,导致浏览器窗口过小的时候部分关键内容(如登录按钮)看不到、无法操作。

交互元素没有无障碍标签。成堆的「未加标签 按钮」。

通过 User-Agent 判断浏览器,并拒绝为某些 User-Agent 服务(但实际上去除这个限制之后,功能是完全没有问题的)。

当没有带声音自动播放权限时,无声播放主体内容(而非等待用户操作使其获得权限)。说的就是 Bilibili。

为大屏幕用户(如桌面用户)展示为手机屏幕设计的页面。这些页面中字体特别巨大,并且不能被浏览器缩放影响。交互元素上鼠标指针不改变为手状,甚至只支持触摸操作而不支持鼠标点击。

悬浮于主内容之上的「在App中打开」。点名批评 imgur。它的按钮不光挡住图片,而且用户放大图片的时候它也被放大,挡住更多图片内容。

不能禁用的图片懒加载,或者视频内容被移出画面、切换到后台就停止加载。点名批评 Telegram、维基百科。我等你加载呢,你非要我盯着看你加载浪费时间?现在网好,你赶紧给我加载好,进电梯或者地铁或者山洞了,我再慢慢看你的内容啊。

视频内容被移出画面就停止播放。点名批评知乎。我让你播放你就给我播放。我不看视频,是因为视频画面没啥可看的,可是我听音频部分呀。

覆盖浏览器的 Ctrl-F 查找快捷键,并不提供方案来避免覆盖。我就搜索当前页面,不要你的站内搜索功能。

注册前请务必先阅读用户条款和规则,用户条款和规则页面需登录后才可访问。

简体中文内容指定繁体中文的字体,或者添加繁体中文的标签。或者反过来。

打扰用户

在内容页面,任何会动的非主体内容,包括但不限于广告、内容推荐。形式可以是动态 GIF、滚动动画、视频等。用于首页渲染效果的背景动画和视频不算,作为主体内容者也不算。

针对非音视频网站,自动或者非用户明确表达地(比如在用户点击不相关内容时)播放带音频的内容。

消耗 CPU 的背景特效。如 canvas-nest。会让 CPU 很吵,也会浪费能源、加剧气候变化。

Category: 用户体验 | Tags: 网页 accessibility
3
26
2022
12

微信消息通知的困扰

一直以来,不得不用的微信以其糟糕的通知体验让我十分不爽。

在手机上,我使用的是 Google Play 商店里的微信。在电脑上,我使用的是通过 Wine 运行的 Windows 版本微信([archlinuxcn] 仓库里的 wine-wechat-setup 脚本可用于安装)。

消息通知不及时

这个问题是最近我的手机日渐陈旧之后我才注意到的。表现是,在一段时间(比如一两天)不使用微信之后,收到新的微信消息或者视频通话,可能会延迟几个小时收到通知。在 Android 通知日志中可以确认,收到通知的时间和消息在微信中展示的时间有数小时之差,并不是因为我没有及时看手机。

我的 Telegram 从来不这样丢消息,即使因为后台进程过多 Telegram 被杀之后,通知只会不能在其它端阅读之后被清除,而不会延迟那么久。而微信,即使它还在后台运行着,却经常占着资源不干活,何况消息通知本应走 FCM。

打开微信即清除所有通知

我有一条微信消息,但是我现在不方便立即回复(比如需要使用电脑而我正出门在外),所以我会让那条通知一直留着。其实以前版本的 Android 系统更方便,可以将通知延后一段时间,只是不能自动指定延后的时间比较遗憾,后来被移除真的太可惜了。

然后呢,比如我要进个超市,或者测个核酸,付个钱啥的,只好打开微信扫码呗。结果所有还未处理的通知全部不见了!等忙完当时的事情,回到家里的时候,我就不一定还记得我还有几条微信消息还没处理了。

多端不同步容易错过

我在用电脑的时候,如果不登录电脑版微信的话,那么我将不会注意到手机上的微信有新消息。那就登录电脑版吧,然后我去上个厕所吃个饭,不用电脑的时候又会错过消息。在电脑端登录的时候让手机上也显示消息通知?那样所有消息都要看两遍,而且消息多的时候还得仔细回想某条消息到底是不是已经处理了。

Telegram 的消息同步做得真好啊。你在哪端用,哪端先给你发通知。其它端的消息会晚几秒出现。一旦在任意端读取了消息,另外的端上的相应消息全部都会被取消掉,不会有消息重复的问题(不过最近好像 Android 上的通知取消变得不那么可靠了)。

手机不可离远

现在电脑版微信终于不需要天天在手机上确认登录了。只要我每两三天登录一次,就可以避免把手机扔去充电了、来到电脑前、又去找手机的麻烦事。——我一开始是这么以为的。直到我发现,我刚刚看到通知、正要处理的消息,并没有在电脑版微信里同步出来。

不知道为什么,微信跟电脑用户有仇似的。明明我有电脑了,不需要凑合于手机的小屏幕和戳戳戳的屏幕键盘了,微信还非得把手机给拉过来。

语音通话不支持耳机接听

某天,我因为沉迷于放置型游戏,把手机扔桌子上充上电让它自个儿玩,自己去睡觉了。第二天早上睡正酣的时候,来了个电话,我拿耳机给接了。然后需要通话的另一方不知道怎么想的,没有商量就发起了微信语音通话,这个耳机根本接不到……

我也尝试过让 Google 助理回拨电话,不过使用不熟练,并没有成功。你说我为什么不起床去接?我睡着被电话惊醒了,还没回过神来啊 QAQ。

4
6
2015
10

GitHub 的一个小细节

这是偶然间发现的。在 GitHub 桌面版网页上,按第一下 Tab 时,会在左上角显示一个「Skip to content」的链接,并且键盘焦点就在这里:

GitHub "Skip to content"

我被这样的小小地惊艳了一下。这个链接可以用来跳过不怎么常用的导航栏上那排链接和按钮。

作为经常打字聊天和写码的人,在电脑前的大部分时间手当然是在键盘而不是鼠标上,所以使用鼠标来进行一些操作很常见。虽然我有 keynavVimFx 来辅助,但是见到 GitHub 这么贴心的细节还是挺喜欢的。

这让我想起了国内的网址,大部分都根本不考虑 accessibility。比如问答社交网站知乎。我早已不「逛」知乎了,只是收到感兴趣的邀请时去看看。因为知乎的体验实在是太差劲了。

知乎取消了所有链接在获取焦点时周围的虚线。这意味着根本没办法使用键盘导航,因为你不知道当然焦点在哪里。

知乎的提交按钮完全无法使用键盘操作。看看 GitHub,写好评论什么的,按一下 Tab 焦点就去了提交按钮上,并且有非常明显的反馈。按空格或者回车就可以提交。如果决定放弃,再按一下 Tab 就好。这两个按钮的顺序是按使用频率而不是相对位置来获取焦点的,因为提交显然比放弃用得更多。Twitter 发送新消息、Google+ 评论的提交按钮也是这样。不过 Twitter 偶尔会需要按两次 Tab 才能提交,大概是改页面的时候不小心给改坏了,过段时间会修好。Google+ 分享新信息时会比较讨厌,因为要跳过好大一堆「添加照片」什么的按钮。

类似的 accessibility 处理,国外著名网站上经常能看到很好的实践,博客上经常能看到大家在关心「少数用户」的使用便捷性。而国内很少有关注这方面的,大家都跟乔布斯一样想,「不管合不合理,我是这么设计的所以你应该这么用」。

比如验证码。不管需不需要,都是字符图。这样盲人就用不了。而国外广泛使用的 Google reCAPTCHA 就可以选择通过声音收听验证码。当然是英语的。反正这全球最大的网站之一已经消失在中国大陆人的视野之中了。我知道专门有人建立了一个 QQ 群,视力正常的人帮助盲人识别验证码用的。

这大概是发达国家与发展中国家的侧面写照的缩影了吧。

最后扔一堆链接:

Category: 用户体验 | Tags: web github 知乎 UX
3
23
2013
16

知乎,谢谢你让我知道 @ 补全可以做得这么烂

因为知乎为我这样的用户设下了许许多多不便的地方,我给他们提过多次然反应甚微。我累了、倦了,对知乎失去了热情。可是,知乎却不肯放过我,经常会收到来自知乎的邀请回答通知。现在新问题被提出来之后,知乎会推荐一些用户让提问者邀请。看来知乎是越来越害怕用户流失了。这和在用户回答之后弄个「分享到新浪微博」(还非常占空间)的行为一样,舍本逐末。知乎不去专心提升其核心竞争力,反而搞一些花哨的东西,不流失掉优质用户才怪呢。

好了,进入正题。为了方便用户,很多网站不但提供 @ 人的功能,而且在用户 @ 人时提供补全。我们来对比一下各网站的补全。

StackOverflow

首先是与知乎同为问答平台,但远比知乎著名和专业易用的 StackOverflow。它在回复评论时 @ 人可以补全。补全效果如下图:

它补全的是参与当前讨论的人的名字。补全提示位于输入框的上方,有点遮住上方的文字了。被 @ 到的人并不会因此收到通知。用户的输入并不会因此被打断,也不需要等待补全结果出现。

Twitter

下一个是 @ 的这个用法的创立者 Twitter。在很多地方均可以补全。Twitter 用户既有一个英文无空白字符串的 ID,也有一个限制更少的名字。补全时两者均会被搜索,如下图所示。

其补全框在输入框下方。补全提示中包含了用户头像、用户名字和用户 ID。最终有效的 @ 只能是用户 ID,因为可以有名字相同的人,但不会有 ID 相同的用户(虽然它也可以更改)。用户的输入并不会因为补全被打断,也不需要等待补全结果出现,只要完整输入要提到的人的 ID 即可通知到对方。

Github

为什么不在光标处显示补全呢?Github 向我们展示了原因:

Github 尝试将补全菜单放到光标处,但很不幸,在浏览器中目前没有准确定位用户光标的办法,所以成这样子了。

和 Twitter 不一样,Github 没有显示用户用户头像,所以没 Twitter 的那样容易识别。

Google+

Google+ 的补全显示也很容易识别,用户头像、名字、圈子都有。如果补全匹配自通讯录中联系人的电子邮件地址的话,此信息也会显示出来——

但是没有用户 ID。因为 Google+ 和 Twitter 不一样,它只有一个用于标识用户的数字 ID,而没有唯一指定某人的人可读 ID。所以,在 + 别人时,用户必须等待并从补全列表中选择要 + 的人。如果你的网络差了点就只能等等了,通常应该不会导致忘记要说的话吧,网络太差的话 Google+ 会没办法正常载入的。还有一点,你无法将事先写好的包含 + 的文本直接复制到输入框。如果你想 + 很多人的话,即使你有需要 + 的人的列表,你也不得不手动抄写一份。

知乎

最后,该知乎上场了!绝对秒杀以上四家的设计!!!

在输入 @ 的时候,知乎会弹一个小框出来——你的输入流被打断了,就不用想着复制的事情了。如果卡了你就只有等待了,但很不幸的是,知乎最近比较卡,一个操作花几秒才完成是常事。只有用户头像和用户名。看看截图里,两个默认头像、三个叫「江南」的用户。更囧的是,提交后我才通过生成的链接知道,他们都不是我要 @ 的那个「江南」!一个同名的不幸的人被打扰了。至于补全项挡住文字这问题可以忽视了,因为被挡住的是光标后边,你没办法接着输入。如果你要输入电子邮件地址,放心好了,补全框会出来烦你的。至于上方「想用 @ 提到谁?」那句废话,大家可以像知乎的其它问题一样暂且忽视。

Mastodon | Theme: Aeros 2.0 by TheBuckmaker.com