自从我来到这家公司，几乎在每个周五的下午或是周一的清晨，不止一次的听到过如此内容的技术支持电话：
(背景说明：此公司从事图书馆行业的软件开发，已有多年经验)

引用:

    技术员tina(以下称tina)：请问有什么能够帮到你的？
    图书管理员wundy(以下称wundy)：哦，我不知道哪里出了毛病，但我的系统无法正常运作了！
    tina：那么有些什么提示呢？
    wundy：没什么特别的内容，只是我在进行还书作业时提示我超期，可是这本书我前几天才借出去的，并没有超期！
    tina：能描述得具体一些吗？
    wundy：具体？没有了，就这些，我也不知道为什么？可是它让我郁闷一个上午了！ 请你们快点解决这个问题，我需要立即开始工作。
    tina：这样……，可能与你的时间设置在关，也或者是你的客户端没有正常连接到服务器，你能ping一下你的服务器吗？
    wundy：ping？什么是ping？在哪里？
    tina：哦（我觉得wundy也许不是太懂电脑），是这样…………
    ……
    (略去数段)
    ……
    tina：找到问题所在了，是你的时间设置的问题，你只需把你windows的时间设置改成默认的格式就行。
    wundy：怎么改呢？
    tina：在控制面板里就行！
    wundy：可是，我没有控制面板！
    tina：哦（天啦，是个电脑白菜），就在你的开始菜单里……
    ……
    wundy：问题终于解决了，谢谢你！只是这问题可真够郁闷的！我觉得你们可以改进一下。
    tina：哦，谢谢你的建议，请问还有什么问题吗？
    wundy：没有了，就这样吧，再见。
    tina：再见。

现在，我们站在交互设计的角度来看一下这个问题：

    * 系统：（系统应该考虑到各种边界因素）系统设计得非常脆弱，对时间及日期的格式有着严格的要求（已不知道这一段代码在第几代的版本中存在了，可是程序员是一个喜欢挑战性的群体，对于这样一件没什么创造力的事物，很显然没有人愿意花时间来来改进它！）
    * 用户：（我们不能要求我们的用户有某方面高深的知识！）wundy显然没有多少关于电脑方面的知识！实际上，在我们的客户群当中，图书馆管理员大部分都是一些小姑娘或是老太太之类(大型图书馆当然会有些牛X的管理员，但公司最主要的客户群不在这里)，他们往往管理着一个小型的图书室，只求能简单易用，生活平淡。对于工作不会有太多激情，不喜欢挑战性的工作！对于挫折他们会选择逃避。
    * 技术支持人员：（显然，tina是最大的牺牲者）tina显然要经常面对这样的问题，并且用户的无知让她得很郁闷。显然，解决这样的问题十次或是二十次并不会带来成就感。相反，这只会让tina小姐越来越郁闷！

我们来分析一下这个问题：据我所知，导致这个问题的原因是我们的更老软件在处理日期过程中，采用了得到系统时间，转换成一个字符串，然后用substr()字符函数分别截取各段得到年月日的方法来得到正确的时间段。而这个方法显然没有将用户的日期格式考虑进去！而新版本的软件又不断延用了这一处理方式。（小公司的软件大多会有各种看似好笑的问题，但它们确实存在），如果用户采用日月年或是月日年这样的格式，将导致时间不正确，于是就出现了上面的N多个技术支持电话！（我们的老板应该感到幸运！因为我们公司的支持电话并非800对方付费模式！否则，他可能需要再多卖50套软件来抵消其电话费用）

站在交互的角度：显然，当我们的软件无法正常获得时间时。软件内部应该能够正确的察觉这种异常，同样的，我们应该用正确的方式提醒我们的用户，让他把时间改回默认的格式，做出正确的反应。而不是把问题封装成“图书借出超期”这种看似不是问题的问题（当然，有很多时候，把问题封装起来也是一个不错的办法，至少让用户提一个问题比让用户提两个问题要好。因为往往因为用户不是专业的人员，他对问题的描述可能不一定能让你了解到真正问题的所在）！

解决此问题的终极办法：很显然，程序员应该考虑到用户自定义日期时间格式这种形式，在考虑到此问题并写出相应解决代码后，我们注意到，用户与系统少了一个交互过程！而此时用户的满意度显然是最高的！

总结：交互设计其实只是为解决复杂的系统与人的相互作用而生，而当我们有能力开发出一套更为简单的系统，把机器与用户之间复杂的交互过程转化为软件系统内部之间的交互时，此时软件系统的的效能与用户的满意度均达到最高。作为一个交互设计人员，看问题不能仅限于看到交互的表面，有时候把头深入水底，把握住问题产生的本质才能提出更为完美的解决办法，就像此例中的的“没有交互过程才是最完美的交互”一样。所以我们也能看到，在很多公司的招聘广告上，招前端工程师的也会要求其能精通一至两门后台语言，其实这就是一种合理的要求！做交互的，只有能把握住整个产品的细节，才能真正做到完美！

原文见http://www.xnight.org/perfect_interaction.html

[ 本帖最后由 XFantasy 于 2007-11-24 12:13 编辑 ]

確實，整體與細節不是那麽容易把握的，好產品不容易啊

以下是我的个人感觉：
这个明显的是程序方面的需求并没有做得很完美。导致了程序出现的错误。
而且你不能期望客户去回答计算机专业知识，这点在做网站的时候也是很明显的。
回来说交互，这个我个人感觉并不算是一个交互式问题，而是本身程序设计上的问题，暴露出来的是技术员和用户交谈的这个社会互动的过程。
    如果不是给程序员使用的工具，本来就应该设计的越简单越好，比如FF和IE，你不能指望一个完全不懂电脑的人去使用FF，给若干的教程，然后还给你普及为什么这个网站不能在FF里面显示正常，那个网站没有支持标准。用户的使用没有问题是最重要的，他不讲究你程序这个黑盒子的内部是如何运算的，他只要结果。

  我个人觉得把这个事情硬扯到交互上有点过于牵强了..

首先楼主的标题有语病：既然不交互，它就不叫交互
楼主的观点部分值得参考，应该充分考虑机器与人在系统中的角色，从而分配不同的任务给他们
“把机器与用户之间复杂的交互过程转化为软件系统内部之间的交互时，此时软件系统的效能与用户的满意度均达到最高”，我觉得这个有待商榷，有时候简单并不一定就是好的
第一：用户很多时候还是比较关心操作过程的，这样可以知道自己在做什么，并可以预见到会得到什么样的结果，使过程更加流畅和人性化，虽然这样会牺牲速率
第二：用户是有喜好的，比如我要从广州到上海，输入出发时间和到达时间点确定，系统经过多方评估告诉我坐飞机是最好的选择，但是可能我有恐高症不喜欢做飞机
等等。。。。
人与人都需要沟通，何况是人与机器？哪怕整个系统只有一个按钮，也需要人去点

噢。。好多字……

" 最完美的交互就是不交互" 不如说成：最完美的交互就是感觉不到交互的存在。而不是没有交互……

感觉不到界面的存在，没有一切屏障，也许就是很不错的产品啦~~~

没有语病，尽管我们谈论的依然是交互，但对于用户来说感觉不到的就是不存在的。
用中国话来说，就是无招胜有招。

交互设计不是“禅”，他有自己的研究与设计方法。

引用:

原帖由 Missx 于 2007-11-24 14:06 发表
以下是我的个人感觉：
这个明显的是程序方面的需求并没有做得很完美。导致了程序出现的错误。
而且你不能期望客户去回答计算机专业知识，这点在做网站的时候也是很明显的。
回来说交互，这个我个人感觉并不算 ...

呵呵,其实这个题目当初自己写的时候也有想过是否不合适,可是暂时没想到更好的,先用着吧

其实只能说在某些情况下,利用程序的功能,对系统做适度的封装,让用户感觉不到系统内部过程的存在,从而可以让用户得到更好体验.

任何事物没有绝对,这题目是起得邪门了点,呵呵

发的贴子只是这几天在看书时并结合公司现有的实际想到一些,说实话,水平还臭着呢! 大家共同学习!

这个标题要看完全文后才能理解，呵呵~ 讲的不错，学习了！

引用:

把头深入水底，把握住问题产生的本质才能提出更为完美的解决办法

细细体味，觉得这句很对

“最完美的交互就是不交互”
非常赞同这个观点，但是完美总是很难做到。

如果把所有用户可能遇到的问题都文档化，并且确定用户都会认真读，那交互就几乎没有必要了。

不过做到这点实在是太难了！

引用:

原帖由 chenzhe 于 2007-11-24 21:23 发表
“最完美的交互就是不交互”
非常赞同这个观点，但是完美总是很难做到。

如果把所有用户可能遇到的问题都文档化，并且确定用户都会认真读，那交互就几乎没有必要了。

不过做到这点实在是太难了！

对于提供帮助文档的这种形式,我并不认同,说白了,如果到了要看帮助文档的地步,只能说明你这一个操作的交互很难以让人理解,好的交互应该是望文而见义的!(就像xml,具有自我描述能力,对于任何平台任何系统任何环境都能做到被正确解析, XML就是个很好的"交互"的例子~~呵呵)

当然,并非反对帮助文档,而只是说,对于一个用户来说,读帮助文档毕竟是件花费时间的事,而且就算用户出现问题了他也不一定会去读你的文档,因为现在的环境下同类的产品往往很多,wendy小姐(指上文中提到的那位)她完全有可能选择其它的产品.

其实完美的境界有很多种,对于一个产品而言,比其它大多同类的产品要优秀,就可以算是一种完美---------------不得不又说得我们公司的图书馆系统,其实就站在一个交互设计师的角度看来,这个产品失败之极(首先说明一下,本人没参与此产品的开发 )!!!比如:
  1. 点A按纽弹出个警告窗口,而点外观一样的B按纽却是弹出一个主窗口.
  2. 超链接样式的文本也被当作按纽使用.
  3. 进入某一窗口后,用户必需在A文本框输入一些字符才能退出这个窗口.
  4. 在刚进入系统时,顶部的菜单栏点击后都会弹出一个只有一个菜单项的菜单!!!
  5. 每弹出一个窗口,都会在任务栏上占用一个位置!!!!(C/S架构的软件,并非基于浏览器的)
  6. .......
但是我公司的产品在较为低端的市场上,在某些区域卖得特别好!!-----------之所以卖得好,很大程序上是因为图书馆软件相对的比较偏门,做的公司少,产品都不够成熟,而我们公司的产品与市场同类产品而言,牛X一点点!这样,就算wendy小姐用得郁闷,当她用别人的产品更郁闷时,她还是会选择你!

引用:

原帖由 fowulover 于 2007-11-24 14:12 发表
" 最完美的交互就是不交互" 不如说成：最完美的交互就是感觉不到交互的存在。而不是没有交互……

在与楼主交互的时候，我被楼主“最完美的交互就是不交互”的表达弄迷糊了，我想我更习惯与用“最完美的交互就是感觉不到交互的存在”这种表达方式的人来交互。

[ 本帖最后由 蓝色汪洋 于 2007-11-25 00:38 编辑 ]

引用:

原帖由 XFantasy 于 2007-11-24 21:46 发表


对于提供帮助文档的这种形式,我并不认同,说白了,如果到了要看帮助文档的地步,只能说明你这一个操作的交互很难以让人理解,好的交互应该是望文而见义的!(就像xml,具有自我描述能力,对于任何平台任何系统任何环 ...

恩，你说的对。我说的的确有一些片面，不能完全依靠文档（FAQ）。图书馆软件的问题一部分问题可以通过软件质量的提高完全避免；一部分可以通过将可能的出错信息融入相关的网页(软件界面)中，其实就是把FAQ分散到各个步骤。但是肯定还是有一些不可预测的因素可能造成错误的发生，这个时候还是需要一定的“电话交互”的。

PS：我认为楼主的标题的确有一些不妥之处，前面那些都应该是交互。应该是好的人机交互不需要人人交互(技术支持)。吹毛求疵了……
不过要说楼主的想法值得我学习，尤其是做网站的时候，这些交互问题其实更加注意。

引用:

原帖由 蓝色汪洋 于 2007-11-25 00:34 发表


在与楼主交互的时候，我被楼主“最完美的交互就是不交互”的表达弄迷糊了，我想我更习惯与用“最完美的交互就是感觉不到交互的存在”这种表达方式的人来交互。

这个表述方式不错。:D

“其实完美的境界有很多种,对于一个产品而言,比其它大多同类的产品要优秀,就可以算是一种完美---------------不得不又说得我们公司的图书馆系统,其实就站在一个交互设计师的角度看来,这个产品失败之极(首先说明一下,本人没参与此产品的开发 )!!!比如:
  1. 点A按纽弹出个警告窗口,而点外观一样的B按纽却是弹出一个主窗口.
  2. 超链接样式的文本也被当作按纽使用.
  3. 进入某一窗口后,用户必需在A文本框输入一些字符才能退出这个窗口.
  4. 在刚进入系统时,顶部的菜单栏点击后都会弹出一个只有一个菜单项的菜单!!!
  5. 每弹出一个窗口,都会在任务栏上占用一个位置!!!!(C/S架构的软件,并非基于浏览器的)
  6. .......”
想对十二楼的说，1到6点是真的站在一个交互设计师的角度看来的吗，那这个交互做得还真不啥样，不是交互的作用不大而是交互根本就没什么做

引用:

原帖由 hysala 于 2007-11-27 11:29 发表
想对十二楼的说，1到6点是真的站在一个交互设计师的角度看来的吗，那这个交互做得还真不啥样，不是交互的作用不大而是交互根本就没什么做 ...

请看清楚括号里的字，我事先说明了我没有参与此产品的开发的，在我来这公司之前，公司根本就没有与前台相关的职位，全部界面都是程序员搞出来的！

我认为最完美的交互应该是让人机直接对话,而不需要同声传译(UI界面)进行翻译. 具体说明参见我的博客文章"好的UX设计就是一个高效的同声翻译器" www.uespace.com

不在明白楼上的意思

交互的过程不就是人机对话吗？

指点一下，呵呵