技术对 UX 的影响

2018年11月7日 | 鹤仙人 | 折腾 |

做一个应用程序有非常多不同的技术选择。使用 Web 技术既可以用做小的开发成本做出跨平台的应用，但是性能和功能又有诸多限制。完全使用原生技术则需要极高的成本。选择技术的因素固然有很多，不同的技术可能实现相同的功能，但体验上是有差异的。

下面介绍的顺序是从更接近 Web 技术到更接近原生技术。

Web 后端渲染

典型的 Web 应用模式，网页在后端进行渲染，配合少量的 JavaScript而构成的应用。这种模式适合交互简单，以内容为主的应用。典型的例子是 GitHub, WordPress, Wikipedia 之类的网站。

后端渲染对服务器的压力更大，每跳转一个页面，浏览器都要等待至少数秒钟。除了 Safari 之外的移动浏览器都有一个刻意而为的点击延迟 (300ms)，这让点击链接跳转在移动端的体验变得更差了。速度是最大的弊端。

单网页应用

使用 Angular, React, Vue 之类的 JavaScript MVC/MVVC 框架制作的应用。前端作为 JavaScript 被整个或部分加载到浏览器。然后只从服务器获取需要的数据，更新页面的部分内容而不需要重载页面。服务器不再需要处理网页渲染，数据可以缓存，数据库查询等耗时操作也更少。这种模式适合交互频繁，数据更新频繁的应用。典型的例子有 Twitter, Facebook, Instagram 之类的网站。

缺点仍然很多：

初次加载仍然非常耗时。
受到浏览器限制，尤其是移动浏览器。
1. 大多数移动浏览器在滚动时会自动隐藏地址栏。如果有浮动元素的话，这会非常讨厌。
2. iOS Safari 强制所有网页可两指手势缩放。这种缩放可能会破坏原有布局，给人一种不可靠的感觉。而原生应用是不可以被整个自由缩放的。
3. 仍然有点击延迟 (300ms)。这是单网页应用给人一种比原生应用慢的最常见原因。
4. 移动浏览器的性能导致很多动画变得缓慢卡顿。
设计/开发模式的问题。
1. Web 开发者通常不会花心思去做手势操作和过渡动画。
2. 在桌面用响应式设计模式开发，并不能完全模拟实际设备的交互感觉。主要问题在于屏幕尺寸，手指的精度和活动范围，以及导航栏和键盘的影响。
3. 桌面和手机共用结构和组件，常常在手机上不太好用。

Electron 和 Cordova

这两个东西都是提供了原生系统接口的 Web 容器。Electron 主要用于桌面应用，只要 NodeJS 可以做到的它都可以做到，因此可以使用非常之多的原生接口。Cordova 或者 PhoneGap 面向移动平台，能使用的接口由插件提供，非常之有限。

加载时间快，不需要下载界面组件。
界面仍然是 Web 引擎渲染的。运行性能仍然比原生差，但是优于浏览器。
相比浏览器，消耗更多的系统资源。
浏览器界面的干扰被削弱。没有标签页，地址栏，更像是单应用。
无法使用一些原生的库和系统接口。

React Native

JavaScript + 原生 UI。一个性能和快速跨平台开发的折中选择。但也可能是一个陷阱。

界面与原生应用几乎没有差异，交互非常流畅。
只提供了原生 UI 组件的一个子集。
可用的原生系统接口有限，第三方 SDK 就更少了。很多功能仍然用 Web 技术实现，变成了混合式应用。
可能会使用更多的资源，启动较为缓慢。

原生应用

原生应用可以在所支持的平台上做尽可能多的优化，取得最好的效果。但代价是巨大的开发成本。

以视频播放器为例，原生应用可以支持任意视频格式，并尽可能优化性能，获得悬浮窗等系统权限。

总结

待续……

正确设置 GNU/Linux 主机名 Hostname 和域名 Domain

2016年8月25日 | 鹤仙人 | 折腾 |

为什么要设置主机名

一些软件需要知道主机名才能工作，不然会有警告和错误，比如 Apache。

可以使用 "hostname" 命令查看现在的主机名，用 "hostname -f" 命令查看完整域名(Fully Qualified Domain Name, FQDN)。如果查找 FQDN 失败，你需要按照以下步骤设置。

个人电脑 PC

PC 通常没有域名和固定不变的 IP 地址。通常情况下，PC 的软件是不需要主机名和域名来运行的。但是如果你开启了某些网络服务，就可能需要它了。

如果你没有注册过任何互联网域名，可以用一个假的，比如 yourname.local ，yourname.lan ，yourname.geek 之类的。因为 .local .lan .geek 目前不是 ICANN 顶级域名，因此不可能和任何互联网站点冲突。例子：

linux-desktop.guoyunhe.local
samba-storage.guoyunhe.local
laptop-1.guoyunhe.local

如果你已经注册了一个域名，像是 yourname.com ，你可以用它来命名你的计算机设备的域名。因为你自己就可以确保相同域名不会被用在别处。例子：

desktop.guoyunhe.me
laptop.guoyunhe.me
old-thinkpad.guoyunhe.me

第 1 步：修改 /etc/hostname 文件。主机名只能包含数字，字母和连字符。

linux-desktop

第 2 步：修改 /etc/hosts 文件。把完整域名 FQDN "linux-desktop.guoyunhe.local" 放到主机名 "linux-desktop" 之前。

127.0.0.1    localhost
127.0.1.1    linux-desktop.guoyunhe.local linux-desktop

第 3 步：重启系统。

检查主机名和域名： "hostname" 命令输出 linux-desktop ， "hostname -f" 输出 linux-desktop.guoyunhe.local 。

服务器

如果你有一个服务器，绑定了多个域名：

guoyunhe.me
www.guoyunhe.me
wiki.guoyunhe.me
shop.guoyunhe.me

你可以选择 "www"， "wiki" 和 "shop" 中的任何一个作为主机名。也可以另取一个，比如 "server" ， "vps-1"。

第 1 步：修改 /etc/hostname 文件。主机名只能包含数字，字母和连字符。

server

第 2 步：修改 /etc/hosts 文件。把完整域名 FQDN "server.guoyunhe.me" 放到主机名 "server" 之前。

127.0.0.1    localhost
127.0.1.1    server.guoyunhe.me server guoyunhe.me www.guoyunhe.me wiki.guoyunhe.me shop.guoyunhe.me

第 3 步：重启系统。

检查主机名和域名： "hostname" 命令输出 server ， "hostname -f" 输出 server.guoyunhe.me 。

验证码：UX 终结者

| 鹤仙人 | 折腾 |

网络验证码技术虽然是外国人发明的，但却在天朝泛滥成灾。

我们有那么多同学去做 UX ，花了那么多心思给用户提供更好的体验。到最后，被一个验证码全毁了。万恶的验证码，以及走不动的进度条，总是最烦人的。

简单的麻烦——淘宝的滑动验证码

淘宝和微博目前使用这个验证码，原理和 Google 的 reCAPTCHA 2 类似。第一步让用户拖动滑块（触屏或鼠标），然后记录鼠标或手指触摸的轨迹，猜测用户是人还是机器。同时还会测试浏览器的排版引擎，JavaScript 引擎等等，确定这是一个人类使用的浏览器，而不是机器人程序。

在滑动过程中，鼠标位置/手指位置的数据是发送到服务器进行验证的（密文，如下图）。由于这一过程很短，采样率有限，而且直线滑动的人为特征性也不是很明显，即使算法再好也很容易被破解程序骗。

如果第一步判断不是人或者把握不准，则进入第二步，即传统的图形验证码。

有没有必要

它挡不住破解程序。滑动验证比图片验证要弱，所以图片验证码才会作为第二道防线。只要写一个程序控制鼠标，并且让鼠标轨迹看起来不那么有规律就可以了。（配合浏览器，骗过浏览器性能验证机制）

如果是通过用户的交互行为来判断其是人还是机器，大可不必显示这个滑块。用户在浏览网站或使用应用的过程中必然要进行大量交互，记录这些数据要比滑动那么一下有效得多。

滑动验证是不能证明其对错的，它的数据和算法都是不透明的，而且可以推测其原理极其复杂。即使用户觉得自己是滑动到了最右端，它仍然可以强硬地不通过验证，给用户一种很无奈的挫折感。目前看来这算法确实有问题，因为通过率出奇地低于文字验证码的通过率。如是玄学，寡人不服 XD

这就造成了两种常见结果：

破解程序没被挡住。
一些用户验证了两步。

在我使用的十次当中，有七次没有通过滑块验证码，而不得不使用图形验证码。滑动和使用图形验证码所需的反应时间其实是差不多的，这意味着我比使用单一图形验证码反而多用了 70% 的时间。

而某些破解程序，已经能够做到 80% 以上的成功率。令人唏嘘不已。

两步验证码的组合更是浪费时间。

我只能说：这不合理。

四处滥用

昨天，有个人在微博上给我发消息，我用 Android 应用回他一下，然后就冒出了验证码，必须要完成验证才能发送消息。然后连续输入错误，消息没有发送成功。

我今天在淘宝注册账号，更改设置，总共输入了十几次验证码。即使我已经输入了短信验证码，后续还是被要求输入滑动验证码。

对于已经登录的用户，验证码通常是没有必要的。如果想验证用户是不是机器人，为什么不在登录的时候提前验证好？如果想验证用户是不是本人，则应该输入密码或者短信验证码。

我在使用 Facebook 和 Twitter 的这些年里，除了短信验证码和手机令牌，从来没有遇到过滑动验证或文字验证码的时候。Paypal 和 Amazon 的验证码也出现得极少，甚至于我都忘记了他们的验证码是什么样子。

当一个交互过程需要安全检查，而人们又想偷懒的时候：加个验证码吧。

验证码是一个在设计过程中绝对应该尽可能避免的东西。不管形式怎么变，用户都会反感，因为它带来了麻烦，且不止一次。它不能保证安全，任何现有的验证码机制都有破解之法。越复杂的验证码，对于人类的挑战也越大。

Sweet Captcha

参考链接

Inside reCAPTCHA – Google “点击验证”的原理和简单破解方法
淘宝滑动验证码研究

MariaDB 全文索引

2016年7月26日 | 鹤仙人 | 折腾 |

MariaDB 和 MySQL 的全文索引的建立方式与查找方式，都和普通的索引不同。

建立索引

建立索引的语法可以简单也可以复杂：

FULLTEXT(title)

FULLTEXT(title,content)

FULLTEXT INDEX post_title_content_ft_index(title,content)

查询

1. 按照自然语言查询，匹配完整单词。比如查询 rabbit 可以匹配 rabbit, rabbits, Rabbits，但是查询 rab 不能匹配 rabbit 。

MATCH(title,content) AGAINST('rabbit')

2. 按照字符匹配查询，从单词开头开始。查询 rab 可以匹配 rabbit ，但是查询 bit 不能匹配 rabbit 。

MATCH(title,content) AGAINST('rabbit' IN BOOLEAN MODE)

多列索引与单列索引

对于普通的索引，如果建立了(title,content)的联合索引，就不必单独建立 title 和 content 的索引，也可以搜索单列。但是全文索引就不行，索引的列必须和查询的列完全一致。如果查询 title ，就要建立 title 单列的全文索引；如果查询 (title, content) 就要建立只包含 (title, content) 两列的索引。

搜索中文

MySQL 和 MariaDB 的全文索引一开始就不是为东亚语言设计的。单词断字是按照空格和标点符号的，但是中日韩文字单词之间没有空格。因此搜索“明月”无法匹配“床前明月光”。使用 IN NATURAL LANGUAGE MODE 只有在搜索整句的时候才能匹配到，基本上没有什么用处。使用 IN BOOLEAN MODE 的时候，只能搜索一句的开头，比如“床前*”可以匹配，而“明月*”就不行。* 通配符只能放在单词的结尾。

因此对中文而言，全文索引反而没有 %LIKE% 的效果好，虽然 %LIKE% 的效率很低。小型网站，可以采用。

MySQL 提供了额外的 ngram 技术，支持每 n 个字符断字。这样就可以用逐字搜索中日韩文字。但 MariaDB 还没有引进此功能。

色情界的一颗新星(伪)

2016年1月29日 | 鹤仙人 | 折腾 |

周一完成了我的 Porn Button 。最开始的设计是比较隐晦的，但老师说不够直接不够大胆，于是最后的设计就比较淫秽了……题目要求是只能依靠触觉反馈，而不能有视觉和听觉传达。充分体现了以往看过的小黄漫中的精髓，简而言之就是还原性行为。

通过压力传感器采集手指按压的动作，电机拉动皮筋和半个气球使之收缩。本来想用一只避孕套的，然而其强度太差，玩不了几次就坏了。最基本的反射是按压的力气越大，收缩越剧烈。松开手指，收缩也会复位。然而这样一点也不智能也不色情乎。微控制器还会计算按压频率，频率升高也会使收缩更剧烈。有点类似生物的反应了。最后还有，如果玩过头就会触发崩坏——整个机器停止工作，需要二十秒冷却时间。（心领神会即可）

最开始想做成这样的盒子。

然而最后必须要用一个木头盒子把内容完全封闭起来，让人看不到里面，以隔绝触觉之外的感官。

盒子上不会标记这个 Button 的主题，因此体验者需要自己体会联想其中含义。但每个盒子有个字母标签方便评分，老师说必须要把“H”留给我……

周一的时候已经给我的一些同学玩过了，都觉得确实是那个意思……嗯。周二展示的时候也获得了强烈反响，相比其他主题这个真是太特殊了。男生比较喜欢，女生的态度则褒贬不一。很多人告诉我她们对我有了新的认识……But, I don't care!

ownCloud 服务器升级 openSUSE

2016年1月15日 | 鹤仙人 | 折腾 |

su

zypper ref

zypper up

sudo -u wwwrun php occ maintenance:mode --off

sudo -u wwwrun php occ upgrade

志愿者模式和激励设计

2015年11月23日 | 鹤仙人 | 折腾 |

我的硕士毕业设计题目是免费的互助共享社群，群体范围限定在阿尔托大学 Otaniemi 的学生村里。租借，共享，共享消费之类点子很多人已经做过了。这个项目的特别之处在于没有资金流动：借得东西，获取帮助的人不需要付费；借出东西，给予帮助的人也不会得到物质回报。当然，也没有押金。

不需要付费会更加方便，也更经济。但是会带来两个严峻问题：

在没有租金和押金的情况下，陌生人之间如何信任？物品的价值如何影响人们的选择要不要信任他人？信任建立的过程中，有哪些有趣的互动？
人们不仅要贡献自己的所有物，还要贡献宝贵的时间。在没有物质回报的情况下，如何激励人们持续贡献，如何给予他们精神回报和满足感？

第一个问题似乎比较容易用实验的方法得到结论，因为我们已经知道在一些案例中，陌生人是可以建立信任的，这就是 Airbnb 的核心理念之一。

第二个问题就难了。继续阅读 →

互联网内容的语言

2015年10月30日 | 鹤仙人 | 折腾 |

世界上的语言有成百上千中，不只有英文，俄文，法文，西班牙文，中文这样的广义语言，还有方言，古语等狭义语言，比如美式英语，英式英语，简体中文，繁体中文，文言文，吴语，粤语等。地理分布越广，文化组成越复杂的语言，其分支往往越多。中文尤其复杂。

如果要设计一个互联网应用，并希望支持多语言，就有很多问题需要考虑。继续阅读 →

霍金：机器人是否会导致人类大规模失业

2015年10月13日 | 鹤仙人 | 折腾 |

译文：

如果机器生产一切人类所需，那么结果取决于我们如何分配这些财富。如果机器生产的财富能被所有人共享，每个人都能享受富足的生活；如果机器的拥有者阻止财富的再分配，大多数人最终会非常穷困。

到目前为止，趋势似乎倾向于后者。科技的发展导致不断增加的不公平。

— 史蒂芬·霍金

原文：

If machines produce everything we need, the outcome will depend on how things are distributed. Everyone can enjoy a life of luxurious leisure if the machine-produced wealth is shared, or most people can end up miserably poor if the machine-owners successfully lobby against wealth redistribution.

So far, the trend seems to be toward the second option, with technology driving ever-increasing inequality.

— Stephen Hawking