Tag: ux

擾人的 lazy loading

維基百科上面有時候會想要看其他語言的頁面，以 Kalafina 這頁來說，想要點開跨國語系的 menu 點日文版頁面的時候，會出現這樣的情況：

游標移上去要點的時候，因為 lazy loading 跑完；DOM 被插入新的 node，造成本來想要的日文版連結跑到下面，然後按快一點的人就點到其他連結... 目前的解法是直接用 uBlock Origin 擋掉那個 node，讓他不要出現：

wikipedia.org##.cx-uls-relevant-languages-banner

這種類型的 UX flaw 在現代愈來愈多了，而且還是各 framework 都推薦的寫法... (各種 useEffect() 類的功能，頁面的結構先出來，再後續讀到內容時再更新頁面)

看到「Creating Perfect Font Fallbacks in CSS」這邊這段時想到的：

With font-display: swap, the browser will first render your text using the fallback typeface you specified in the font-family property[.]

font swapping 也是個讓人吐血的 UX flaw...

更激進的考慮使用者會混淆的問題

前陣子寫的「UUID 的 UX」考慮到了人眼會把 0Oo 以及 1IiLl 看錯的問題，這篇則是更激進的想辦法去避免類似的問題：「Understanding and avoiding visually ambiguous characters in IDs」，對應的討論可以在「Understanding and avoiding visually ambiguous characters in IDs (gajus.com)」這邊看到。

作者有提到，這是用在人類需要寫下或是溝通時，避免錯誤的發生：

Any time that the ID might need to be communicated verbally or written down[.]

這就不只是前面提到的 0Oo 與 1IiLl 問題了，包括看起來有機會誤會的字，像是 2Z 以及 8B 這種也要避開。

如果是大小寫都放進去的話是 53 個字可以用，但如果希望大小寫意思一樣的話就只剩下 22 個字可以用了：

Assuming that you are going with case sensitivity, you have 53 characters to choose from (adjusted for visually ambiguous characters). On the other hand, if you decide to make your IDs case-insensitive, you have only 22 characters to choose from.

他給出了這 22 個字：

[
  "a",
  "b",
  "c",
  "d",
  "e",
  "f",
  "h",
  "i",
  "j",
  "k",
  "m",
  "n",
  "o",
  "p",
  "r",
  "s",
  "t",
  "w",
  "x",
  "y",
  "3",
  "4"
]

後續還提到 rn 與 m，以及 vv 與 w 的相似問題，不過這邊的 generator 就更難搞了...

搞到這樣，乾脆用數字就好？使用者的 UX 也比較好？

UUID 的 UX

在「The UX of UUIDs (unkey.dev)」這邊看到的紋章，原文在「The UX of UUIDs」。

裡面有不少是有幫助的建議，像是第一個建議是把 UUID 裡面的 - 拿掉，這樣對於 copy 比較方便 (畢竟大多數人應該是 copy UUID，不會是念出來？)。

第二個建議是加上 prefix，這點不一定侷限在 UUID，只要是 token 上面都很適合。這個在不少系統上應該都有看過，像是 GitHub 的 token，或是 AWS 的 token 都算是這類。

文章裡面沒有提到，但這個建議也可以幫助你在 CI 上設定 regex，擋下把 secret token 寫進去的行為。

第三個提到用 base58，一方面是減少長度，另外一方面是想要避免 1IiLl 與 0Oo 的問題，這點我覺得還好... 既然都是 copy & paste 了，我覺得拿 base62 (i.e. 大小寫加上數字) 不錯，這避免特殊字元無法選擇到，也就是文章裡面第一個建議。

第四個建議是建議重新思考 range，因為 UUID 的 128-bit range 很大，但不是所有應用都需要用到這麼大的範圍確保 collision-free (於是可以當 primary key)。

這點讓我想到 X (Twitter) 當初發表的 Snowflake ID，在 Twitter 這種規模下 64-bit range 也已經夠用。

後面的文章內容就是在推銷自家東西，我就... 跳過了。

uBlock Origin 1.48.0 的改善

Hacker News 上看到「uBlock Origin 1.48 adds readiness status, code viewer, and other fixes (github.com/gorhill)」這則消息，uBlock Origin 在 1.48 有個蠻重要的 UI/UX 改善 (Readiness status at browser launch)。

uBlock Origin 預設會搭配「工人智慧」維護的列表，這些列表通常都不小，在剛開瀏覽器，還在讀取的過程中去看網站會遇到阻擋不完整的情況。

先前沒有辦法知道這個問題，在這版加上了對應的 icon color 來解決，黃色表示還在讀：

這時候跑去逛網站的話會出現驚嘆號：

讀取完後 icon 會變成標準的紅色，但驚嘆號仍然會留著，表示這個頁面未必有完整過濾：

正常有阻擋的則是這樣：

理論上可以減少 bug report XDDD

To reduce the number of reports caused by this issue which is outside of uBO's control, uBO's toolbar icon will now reflect its readiness status at browser launch.

Mac 會自己改變 Desktop 位置的問題

以前好像沒遇過，換了 M1 以後才注意到 desktop 位置位自己被改變，覺得很阿雜... 找了資料才發現是個 "feature"：「How to prevent Mac from changing the order of Desktops/Spaces」。

關掉就好了，網路上的資料最早出現在 2018 年左右，大概是那個時候被加進去的？

Banner blindness

前幾天的 Hacker News Daily 上看到「Why do people not notice our enormous, prominent, clear and contrasting purple banner?」這篇 2018 年的討論，裡面在講為什麼使用者會常態性忽略 banner 的內容。

在答覆區裡面有人提到了維基百科上面的 Banner blindness 這個條目，題到了網站的使用者會刻意或是非刻意的忽略掉像 banner 的資訊：

Banner blindness is a phenomenon in web usability where visitors to a website consciously or unconsciously ignore banner-like information. A broader term covering all forms of advertising is ad blindness, and the mass of banners that people ignore is called banner noise.

開頭也提到了 banner 廣告 CTR 的變化：

The first banner ad appeared in 1994. The average click-through rate (CTR) dropped from 2% in 1995 to 0.5% in 1998. After a relatively stable period with a 0.6% click-through rate in 2003, CTR rebounded to 1% by 2013.

所以這個現象有個專有名詞來形容...

如果把 OpenSSL 包裝成 GUI 版本

在 Hacker News Daily 上看到這則，蠻有趣的嘗試，如果幫 OpenSSL 包裝成 GUI 版本的話，可能會長的樣子：「If OpenSSL were a GUI」，而 Hacker News 上對應的討論在「If OpenSSL were a GUI (smallstep.com)」這邊可以看到。

要注意的是這是 mock 出來的圖，而不是真的有人這樣幹了一個版本出來。主要是在帶出 OpenSSL 這個工具極度複雜的問題，另外也因此帶出 GUI application 的取捨問題，在 Hacker News 上的討論都有人提出來。

不過讓我吸引的點反而是 mock UI 的選擇上，看起來作者選了 Platinum 風格 (Mac OS 8 & Mac OS 9)，在維基百科的「Appearance Manager」這個頁面有提到：

The default look and feel of the Appearance Manager in Mac OS 8 and 9 is Platinum design language, which was intended to be the primary GUI for Copland.

是個讓人懷念的風格，而且意外的看起來反而讓 GUI 柔和不少，而且其實就功能性來說還蠻不錯的？

Firefox 的 UI/UX 歷史

在 Hacker News 首頁上看到「Firefox UI/UX History (github.com/black7375)」這篇，整理了 Firefox 的 UI/UX 歷史，裡面也試著分析各個不同版本的優缺點。

話說看到這個最早的版本的 screenshot 讓人懷念 (還叫做 Phoenix 的版本)：

裡面也提到了一些 fork，像是「Early (v1 ~ v3)」這個 UI 版本的 fork 還可以在 SeaMonkey 看到。

到了「Classic (v4, 2011.3)」這個版本，目前還有在維護的 fork 則是 Pale Moon，不過核心的部份沒有跟上，很多網站的新功能是沒辦法用的。

接著是「Australis (v29, 2014.04)」這個版本，目前已經沒有在維護的 fork 了，2021 年年底 Basilisk 宣佈停止維護。

然後是「Photon (v57, 2017.11)」這個版本，目前還有在維護的 fork 是 Waterfox 的 G3 系列。

目前最新的一個是「Proton (v89, 2021.06)」這個版本。

密碼輸入上的 UX

Hacker News 上看到「Gmail password first character is case insensitive on mobile device (support.google.com)」這篇，在講密碼輸入上的 UX。

在 Hacker News 上的討論看到這則：

This is a well-understood feature. Facebook does the same thing[0].

Quote:

Facebook actually accepts three forms of your password:

* Your original password.

* Your original password with the first letter capitalized. This is only for mobile devices, which sometimes capitalize the first character of a word.

* Your original password with the case reversed, for those with a caps lock key on.

[0]: https://www.zdnet.com/article/facebook-passwords-are-not-case-sensitive-update/

接受三種密碼，第一種是完全正確的密碼，第二種是第一個字如果是大寫時的密碼 (在行動裝置上可能的行為)，第三種是大小寫全部相反的密碼，這在沒注意到 caps lock 時會發生。

強度不會削弱太多，但對於 user experience 好很多的設計。

讓手機上瀏覽器自動帶出數字鍵盤的方式

在「HTML attributes to improve your users' two factor authentication experience」這邊看到關於讓使用者輸入 2FA (通常是數字) 比較流暢的設定。

原始是上面這張這樣，目標是希望下面這張這樣，當透過 SMS 2FA 時可以提供選項直接貼上，而且也自動帶出數字鍵盤：

給出的幾個重點在於 inputmode、pattern 以及 autocomplete：

<input
  type="text"
  name="token"
  id="token"
  inputmode="numeric"
  pattern="[0-9]*"
  autocomplete="one-time-code"
/>

查了一下 caniuse.com 上面的支援度，pattern 基本上都支援了，autocomplete 在這邊用到的 one-time-code 基本上也沒問題，只有 inputmode 這邊支援度比較差，IE11 (基本上不會更新了)、Firefox 與 Safari 沒支援。