交互设计这件事

本文地址:https://blog.hoppinglife.com/?p=9

最近有两个客户端让我很闹心。

Android上的Twitter客户端Carbon更新了,新的Carbon有一个很漂亮的界面。(图片摘自Google Play)

问题?——我找不到我想要的功能在哪。

按Menu键没有反应,按返回键会退出程序,按那个加号是发新推。设定呢?帮助呢?为什么点twitter里的链接没有反应?

经过一段时间的研究,我发现打开菜单要点右下角你自己的头像——是的,那个加号和右边的头像不是一个按钮。是的,想要搜索、设定或者查看教程(教程藏在设定里面,如果你能找到教程,基本上你已经会用这个app了),你得猛击自己的头部——我的头很圆吗?和搜索功能有什么关系?

想要查看twitter的List,从边缘的右向左滑,但是要小心,如果你从中间滑,那你会来到conversation页面。用两个指头向上滑会跳到最新的tweet,但是要小心,如果你不小心用两个指头点中了一条twitter,那你会触发retweet功能。想要点击twitter里面的人名和链接?你要先点一下twitter,但不要点最左边发推人的图片——那会访问那个人的profile。——要想看到全部的对话,你要再点击一个按钮。

另外一个类似的应用是BeyondPod – 这是个podcast播放软件。在这个软件升级了新的版本之后我有两周都找不到怎么调整播放进度——没有提示,没有按钮;直到今天我不小心滑动了一下,发现『Now Playing』页面藏在播放列表右边。

这些软件坚定了我的判断——今天的app设计者,越来越把『酷』看得比『易用』来得重要。手势的滥用,就是最明显的例子。

其实,在我看来,今天的『手势』,其实和『命令行』没有什么不同:

-在GNU Screen的界面下,按<C-a><C-n>可以切换到下一个窗口
– 在Carbon主页的边缘从右向左滑动,可以调出list功能
-在FreeBSD下,ps aux会列出所有进程,包括它们是由谁调用的

有很大的区别吗?手势滑动看上去比命令行来得简单,但是它们同样要求用户记忆——哪个屏幕,哪个功能应该怎么调用。区别是,我愿意花时间学习shell来工作,我不想花时间学习怎么快速发推。而且在命令行下,我起码还有man page和–help可以救急。

我至今还记得第一次在展会上看到Windows 95——当时7岁的我只花了60s找到『扫雷』。除了『好看』,GUI的最大优点在于『易用』。这就是我们为什么愿意忍受繁多的菜单和按钮——当我需要一个功能的时候,我不用查阅500页的manpage就能找到它。

今天的交互设计师似乎早就忘了这件事——他们喜欢『最小化』和『直觉式』的设计,换个说法,他们喜欢把所有界面的功能都藏起来,让用户用第六感来找到它们。不幸的是,我的第六感和它们从来步调都没一致过。拜托,我的第六感有个名字,叫做Android Design

最后,对于有耐心看到这里的朋友,弱弱的问一句,Spotify新版里,怎么随机播放一个歌手所有的歌曲?

场外因素

本文地址:https://blog.hoppinglife.com/?p=4

(新网站缓慢建设中,尚无具体时间表。)

想了很久第一篇新Blog要写什么,现在想想就从天天在用的软件说起吧。

和很多同龄人一样,我开始接触编程的时候使用的是Turbo/Free Pascal/Lazarus的IDE, 后来转向C的时候用Dev C++/Code::Blocks, 接触Linux之后开始使用Emacs,用过一段时间的Eclipse写C/C++/Python/Java, 再后来开始长期使用vim/IDEA进行开发 – Java/前端代码用IDEA写,后端代码用vim写。

Coder总会不可避免的陷入圣战的泥潭 。 一开始是vim vs Emacs vs VS, 后来是Eclipse vs IDEA,再后来是vim vs sublime text, 总之有coder的地方就有江湖,有江湖的地方就有圣战。——这还只是文本编辑器。

不知道有没有像我一样的人,曾经觉得*nix下面没有一个出色的C/C++ IDE有那么一点奇怪(虽然Windows下大概也Visual Studio+Visual Assist X还活的比较好)。——几年之前最流行的组合包括vim/omni-complete和emacs/CEDET,用起来多少都有点奇怪,远远没有VS初上手来得正常。

大家似乎都这么想: 平均每3天我就会在不同场合看到论证Vim设计得很糟糕的文章。——反人类的设计,三十年前的键盘映射,糟糕的插件管理和界面,只是用来装X, 快点用acme/textmate/sublime什么的代替它吧。

但是大家还是在用vim/Emacs:如果有人问我做Linux下的C/C++开发用什么IDE, 我还是会说vim/emacs,十年之前是这样,十年之后还是这样。甚至今天的我,会费力把每个我会写字的地方都改成vim key-binding。

是的,我知道vim是很糟糕的设计,我知道配置它很麻烦(实际上有了vundle/janus/spf13之后并不复杂),我知道它的语法识别并不出色,但我还是会用vim, 哪怕我要专门写个脚本来生成我的.vimrc.

因为这个世界上,『最优秀产品』评选,有很多『场外因素』。

  • 通用
    有机器的地方就有vim——不管windows/Linux/BSD,不管是server还是树莓派,不管是android还是ios, 我都可以轻松的找到一个vim(至少是vi)来用。更重要的是,让这些vim长得用着都一样,并不花太多力气。
  • 社区大小
    成百上千的coder这么写代码——不管是配置、工具链都已经非常成熟了。毫不夸张的说,只要你想到的idea, 就有人或多或少的实现在vim里。每当想做一件什么事的时候,搜搜vim tips wiki就找到解决方法了:庞大的社区,能够相当程度的减低学习的难度,也能够轻易的让你体会到社区的最新成果。
  • 路径依赖
    是的,当你已经适应了一种工作方式了之后,你会懒得更改到另一种工作方式。
    毕竟,在ssh下工作,选择几乎只有vim/Emacs.
  • 免费/轻量
    是的,不用支付额外的费用,可以直接在ssh上工作,节省屏幕空间——大家都挺穷的。
  • It just works.
    大家已经这样写代码写了很多年了,至少说明它没有大问题,何必花精力改它——发掘一个更好用的toolchain的时间,很可能超出你的想象。

这并不是说vim/Emacs不优秀——实际上它们优秀到超乎想象,那部分内容和本文无关;但我相信如果今天再去设计vim/Emacs, 肯定不会长成它们现在这样子。但是这无关紧要。那些『场外因素』,已经或者弥补,或者让我们忽略了它们的缺点;也让我们离不开这些老家伙的『特性』。

 

同样的道理也适用于C/C++/Java/Unix/make/tex:如果今天重新设计这些东西,它们很可能会长成Go/Rust/D/Dart/Plan9/Scon/texmacs的样子。但是绝大多数情况下,这种关公战秦琼式的比较毫无意义:后者的优点和这些『场外因素』比起来,并不重要。更何况,让前者变得方便使用,比让后者变得成熟,要简单太多。

所以我从来不是很买『那个设计不好所以应该换』的帐。用户从来不傻:站在巨人的肩膀上或许不难,但是真正成为巨人远没有那么简单。