征集方案：永不完美的设计之搜索联想词被遮挡

代总管 · 发表于 2009-12-22 00:48:23

WebPPD开通两周年，首次举行Web设计讨论的征集活动。
大家集思广益、各显神通，由此话题展现各位的思考、讨论和尝试解决方案吧。
提供尝试解决方案优秀者，获得主题悬赏虚拟币100枚，并授予实名认证勋章。

搜索引擎联想词会被输入法提示框所遮挡
——永不完美的设计

是因为外国人输入英文不需要输入法给个提示框吗，
我们输入中文时基本都会有个输入提示框跟随，
这样的跟随框有什么不妥吗？
有的时候，也许会这样。
特别是下面这样，你希望随时根据用户的输入提示不同的联想词建议时。
简言之，
就是搜索引擎的联想词和输入法的联想词在同一提示位置上出现了冲突。
如何化解这种冲突，期待优秀设计师的解决方案。

以下内容：被遮挡的联想词

尹广磊 · 发表于 2009-12-22 00:48:24

最佳回复请看此楼：http://www.hiaxure.com/thread-461-1-1.html#pid2230

刘助理 · 发表于 2009-12-22 10:01:04

有两人提了解决方案：
一个说，让输入法的提示框可以变得半透明。
另一个说，让搜索引擎的联想词位置向下错两行，错开输入法提示的位置。
（竖排提示的输入法，可能错开的位置要多了。）

赵野 · 发表于 2009-12-22 10:05:32

改输入法不太可能了
从网站入手
时间有限，没有考虑周全：）
先抛砖，等着玉！

第一个，联想词放到右边，宽度缩短
第二个，布局不变，鼠标移到联想词上，对应词条覆盖搜索框，使用半透明悬浮效果。

尹广磊 · 发表于 2009-12-22 10:17:02

向外延伸一下，输入法提示框遮挡的情况。

阿利 · 发表于 2009-12-22 11:29:05

一根弦 · 发表于 2009-12-22 11:59:17

本帖最后由一根弦于 2009-12-22 12:02 编辑

方案A:改变输入框位置
【输入法提示】与【输入框】在同一行；
随着【输入框】输入的增多，输入框水平右向移动（由于是处理搜索，搜索字数相对有限）

方案B:改变搜索联想词位置
【搜索联想】空出【输入法提示】高度的空白，默认空白下的第一行为首行。

枪毙自己 · 发表于 2009-12-22 12:14:40

本帖最后由枪毙自己于 2009-12-22 12:18 编辑

这个前几天看到别人提出过这个问题，思考过如何解决。
目前思考的结论是：

方案一
1、在搜索框上加一行代码，设置禁止输入法。
这样的话，在输入框就只能输入英文字母了，之后采取google的方式，匹配词库，找到拼音相关的条目，列出来。
2、备选中最后一个是”手动输入“选项，选这个选项，自动设置（或者采取替换方式）输入框为可以开启输入法的输入框，这个框可以不显示推荐结果。
2.1 如果要开启推荐结果的话，默认结果列表上面空一些位置，但是这个留白大小的计算无法精准，放弃。
2.2 将推荐结果置于输入框上方，虽然有悖于传统select单的使用习惯，但也不是不可行。

总结：在用户输入中文，但是文字还没有选定的状况下，就给定用户推荐的搜索结果，其中包括中文，这种方式其实类似于输入法自己的选字功能。在这种情况下，一边输入中文，要从输入法中选字，又要在推荐搜索结果中选，两个选择并发，用户并不知道先后顺序，实际上过程是按照习惯先扫描一个，没有想要的再去扫另一个，另一个也没有再继续修正输入内容。
　　这种方式本身并发情况就不利于操作，必须消灭掉一个，此方案的初衷是消灭掉输入法的选词框。用推荐搜索结果代替输入法的选词。
　　但以上方式改变用户使用习惯较大，不推荐。

方案二
　　１、在输入中文的过程中，输入法没有最终确定选词之前，不出现推荐搜索结果。（与google、有道、bing相反）
　　２、输入完毕后，推荐搜索结果不是很满意的情况下，用户手动删词，加词，减词，这样也提高了用户对于电脑操作的信心度。对中英文判断也更准确。

总结：此方案的目标也是干掉并发的选择，但这个方案的目标是干掉并发中的推荐搜索结果。
　　用户默认开启中文输入法，输入文字时，默认用户的输入目标是中文，如果输入错了，用户自己关闭输入法即可。所以这时去猜测用户的搜索目标，精确性低，也有失礼貌原则，好比你和一个人交谈，你刚说了”我爱吃“，他就告诉你”你爱吃糖吗？“，然后你又要去纠正，说”我爱吃肉“或者其他。
　　等待对方说完，这是一个基本礼貌问题，对于网站来说，实时的反馈，对用户的帮助有多大呢？我没有用户在输入法输入到一半就跟着推荐结果跳转到搜索结果页的数据，但是等用户输入中文完毕后再去推荐，毕竟大多情况下没有漫长的等待，所以建议在中文输入法输入过程中，不要提示，还是等输入完毕后，再作推荐。　　
　　这样做的好处还有一个，在用户输入完之后去做推荐，在推荐结果中就可以有偏向性的推荐，例如“mao”，那就是英文的mao，“毛”可能是中文的“猫”，“矛”。让用户找到对电脑的控制感。
方案二测试代码,copy到txt文档保存，改文档扩展名为htm即可：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>测试</title>
</head>
<body>
查看：<input id="aa" type="text" readonly="readonly" style="border:0px solid #FFF;" onfocus="document.getElementById('in').focus();" />
<br />
在此输入文字：
<input id="in" type="text" onkeyup="document.getElementById('aa').value=this.value;" />
</body>
</html>

复制代码

方案三：也就是之前大家说的，错开输入法选词面板；
　　可以让推荐搜索结果左边左移１００像素，这样虽然还是基于select的基本心智模型，但左扩１００像素，多少也会有不习惯，但是为了让这种并发不互相影响，也只有这样了。
　　再有就是彻底打破select的心智模型，让推荐搜索结果向上弹出（适用于不会将搜索框滚动到页面最上方的情况，即一屏基本上就能将搜索框显示在垂直居中的问题）。或者将推荐词条离开输入框，向下移50像素，用另外一种模式展现，例如表格…… （具体待推敲）

总结：以上三种方式，个人倾向于第二种。虽然看似是对于google搜索帮助的一个退步，但个人认为之前google所做的这种中文未输入完就做的推荐，实际上是一种费力不讨好的行为，因为本身遮挡的时候，用户确认当前选择，看结果即可，但是随之而来有人提出遮挡论，好像有了遮挡就无法用，那么消灭遮挡的话，使用第二种方案，使用最基本的代码就可以完成，但是google为了实现目前这种方式，反而用了更多代码，实则是费力不讨好啊……
　　目前可能更多人提出的方案是第三种，但是这种要根据不同情况设计不同的位置，很难标准化，请给出一个具体环境，例如ｇｏｏｇｌｅ搜索引擎，或者ＭＳＮ联系人查找，然后具体再设计风格。

以上本人卓见，欢迎批评指正和讨论以及人身攻击，但谢绝骂娘等无品行为，谢谢。

枪毙自己 · 发表于 2009-12-22 12:22:08

原本输入的内容越少，推荐的结果越多，可选择范围更大，挡住也无非只有第一行的，何况输入法可以随时确认当前选择并关闭。
随着输入内容的增加，推荐结果越少，这时候每个待选的权重就更高，就更怕遮挡。但这时随着光标右移，输入法选词框也右移，左侧遮挡会露出来，也就没有遮挡问题了。

本身这个设计的问题没那么严重，一切并没有想象中那么糟，哈哈。

枪毙自己 · 发表于 2009-12-22 12:29:44

一般来说，一个产品的优秀，并不是因为他100%完美，而是核心功能是否完善。
如果要挑出bug，也都是分优先级的。
假设自己要做一个类似的项目，上线前，测试人员揪着你说 select 框的边框和网页内容区块的边框风格不统一，一定要改了才能上线。
那么，可以把他改为伪select框，或者为了速度、设备间的兼容性等不去改他。
问题的关键是在于项目中这个select框的是否是核心功能，是否影响了整体操作的流畅性。
这就是一个28理论，为这个细节付出80%努力，你所得到的回报或许20%都不到。

作为产品经理，不应该是揪着交互细节不放，有更多的事情需要我们考虑。
当然，有时间的话，还是做的越完美越好，不过目前这种情况，在付出和回报比不高的情况下，产品经理们还是把更多的经历放到用户需求，盈利模式，运营方式上面去，打开视角才能获得更高回报。

将UE放的太大，只能让你在其他方面失去更多关注，毕竟产品经理的时间和精力也是有限的，完毕。

枪毙自己 · 发表于 2009-12-22 14:05:36

Sorry,方案二的测试demo我又测了一下，问题出在我身上。
我刚才只用了qq输入法测试，qq输入法在确定选字之前，是不将文字type到input框中的，所以使用qq输入法的话，第二种方案可行。
但是使用google输入法、微软拼音输入法的时候，这两种输入法在确定选字之前就将文字tpye到了input框中，所以加事件 onkeyup来获取input的value值，会获取到确定选字之前的待选文字，也就出现了现在google有的情况。
而改用onchange，则只有光标离开input框才会执行。
所以，第二种方案不成立，或许可以通过一些技术来解决这个问题，但是所付出的代价是不值得的，根本问题是输入法和浏览器这两类软件的核心功能设计。

综上所述，与其花费大量精力来调整和实现第二种方案，或者采用让用户疑惑为何无法打开输入法的第一种方案，都不如采用第三种方案来的更便捷。

但第三种方案，在通用性不强的情况下，每次使用都要结合环境去制定一个新的规范，不如保留现有方案，即：放置遮挡不管，让用户自行关闭输入法或自行输入想要的文字。

尹广磊 · 发表于 2010-1-1 00:10:50

转：为中文而设计的文本框
时间：2009年12月4日 | 作者：大脸

我一直觉得，文本框的这个东西，在有输入法的国家，是我们这些懒人的杯具，文本框的自动完成功能，在配合输入法下，简直是个鸡肋。一次次的切换Ctrl+Space，是否有让你崩溃想敲烂键盘呢？

上面的那张图已经很明显的让我们感觉到了三个问题：

1. 输入法把自动完成遮挡住了，我看不见。
2. 使用键盘↑↓键只能切换输入法内的选字，无法选择自动完成内的选项。想用却用不到。
3. 当你懊恼的打算用鼠标去点自动完成列表内的文字时，杯具发生了，你发觉，你点了，事实上什么效果都没有。你的文本框变成一遍空白。（在Chrome下多种中文搜索引擎有此问题，杯具啊。）

备注：经过笔者测试多种搜索引擎在不同浏览器的呈现效果，这三个问题出现的几率各不相同，但在chrome下这三个问题非常明显。（Chrome渲染有问题？）

关于问题一

在Chrome下似乎没有解决方案，所有的搜索引擎表现都如文章开头的图片的效果。

IE下，大部分的搜索引擎都采用了一种笨可是最有效的方法：只有文字被完全输入到文本框内后，自动完成才出现，这样就避免了遮挡的问题了。

在FF下，大部分搜索引擎也是采用与IE内的做法，隐藏自动完成。当然，也有笨家伙：百度和有道，在FF下依然还是遮挡住了。

关于问题二

因为在IE与FF下大部分搜索引擎采用了上诉的的方法避免了出现输入法与自动完成，所以这个问题主要是出现在Chrome内。从实际的测试中发现，国外的搜索引擎表现更佳。

在Chrome的Google与bing搜索，如果使用↑↓键，是可以选中自动完成的，当然，你的输入法选字也同时切换了。

当然，也有笨家伙：Chrome下的所有中文搜索引擎，以及FF下的百度和有道，依然还是无法使用↑↓键选择自动完成。

关于问题三

好了，我就直接说笨家伙吧，这次上榜的还是百度与有道。但是百度这次可以欣慰了：有道垫底了。有道在FF与Chrome下鼠标点击自动完成后，文本框都会自动消失。百度只在Chrome下出现此问题。

说明这些问题并不是表示我强烈的鄙视中文搜索引擎，相反我更爱好他们。但我们需要考虑的问题是：在设计文本框的时候，是否应该更加考虑到一个现实：所有的中文用户都在用输入法输入文本框。我们的操作比英文用户更复杂。

在输入的时候，中文用户多了一个翻译的步骤，把键盘上的字母翻译为中文汉字。这也是中文用户偏爱鼠标操作的原因，因为输入的工作太复杂了，虽然我们的输入法在近几年有着超越的发展，但对于用户而言，这种门槛还是存在的。——至少我的爸妈想使用电脑打字，他们就不得不去学拼音。

那么，为了使用户少按一次ctrl+space，让用户操作更流畅，在文本框的设计上，我们必须更加细致与谨慎。我个人总结有以下几个方法。

禁用输入法

如果某些文本框只允许用户输入字母符号以及数字（如登陆界面的“用户名”），那就禁用输入法吧。

网易邮箱的登陆界面就采用了这种方法，Web界面的实现手段很简单，只需在CSS代码内加上：ime-mode:disabled;

当然，目前很多产品的登陆界面都进行了相同的处理，不妨挖掘下更多产品内部的文本框吧。如验证码输入框。

用户输入之后才提供响应

只有用户把文字输入到文本框内才提供响应，这是主要是针对一些自动完成和即时搜索（输入后自动搜索）功能的。

windows7的资源管理器的搜索框为即时搜索，但文字还在输入法内时，它并不启动搜索。这样的设计能让界面更简洁且让用户容易理解。

提供正确的键盘反馈

如前面Chrome的下的Google，还是支持↑↓键选择自动完成的，这样至少保证了，在使用输入法的时候，用户的一些按键还是有效的。

当然，我也见过一种很白痴的界面，他对Enter键的感知错误（Enter键在输入法内常用作用是输入英文字母），截图我无法找到，但大致是这样。

注：下图是我PS用以说明问题案例（因为暂时找不到真实案例），并不代表其真实情况如图所示。

按下Enter之后，系统自动响应了默认的“登录”按钮，但事实上我只是想把邮件地址输入文本框而已。明显的键盘反馈错误。

用户输入之后才提供响应

只有用户把文字输入到文本框内才提供响应，这是主要是针对一些自动完成和即时搜索（输入后自动搜索）功能的。

windows7的资源管理器的搜索框为即时搜索，但文字还在输入法内时，它并不启动搜索。这样的设计能让界面更简洁且让用户容易理解。

尝试使用拼音识别

毫无疑问，拼音识别能够有效帮助中文用户，就算他没有使用输入法，同时也有可能帮他纠正一些汉字输入错误。

史上最佳中文文本框？

我把这个讲颁给QQ邮箱的写信页面收件人文本框，原因有三个：禁止输入法，块状结构，拼音识别。如果你把联系人都加了中文名字（火星文就没办法了），试试输入10个人的邮箱地址，你的速度有多快？告诉你，我只需要25秒。

从图中可以查出，这个文本框是支持拼音识别的，同时，他采用了块状结构，邮件地址是整块被删除或增加的。

无疑QQ的设计值得学习。

史上最差中文文本框？

我要把这个奖颁给新浪微博的登陆框，当然，他们最近改进了这个设计，不过，这个反例，值得我们吸取教训。

如果在这个图内还存在输入法的输入框呢?够杯具了吧,OK,我想这个图已经算是文本框设计的经典反例了,欢迎大家膜拜学习。

写在最后

文本框是一个很细节的东西，因为他属于一个用户信息收集的有效控件。而我们的中文用户，值得拥有它们自己的特色文本框。

在设计的同时，我们更应该考虑到用户的输入法状态。

文中的测试皆采用搜狗拼音输入法测试，如有不正确的，还请指正。

备注补充

关于搜索引擎的文本框反映的上诉问题，根据留言者 jane的意见。我也认同，或许，这个可以通过输入法来进行整合。

有没有那种可能，输入法能够读取到搜索框的自动完成列表，那么这样，我们只需输入的时候按一个切换键，就能很直观的使用自动完成功能了。

以下是我发明的CCAV搜索品牌

skylovemm23 · 发表于 2011-11-17 16:48:38

受益

Hanami · 发表于 2011-11-17 20:56:28

哇咔咔 · 发表于 2011-11-28 12:24:04

不错

为爱而生 · 发表于 2013-3-27 16:45:06

学习了 M

[交互文章] 征集方案：永不完美的设计之搜索联想词被遮挡

最佳答案

输入法提示与输入框在同一行，输入过程中，视线水平扫描。

转：为中文而设计的文本框