整合状态按钮和导向按钮

Demo

延伸阅读：
状态按钮和导向按钮

未知选项的表单设计

发现许多的注册表单设计中，性别部分的设计大都这样：使用单选按钮（radio）并默认选中一个（大都为男性，某些女性频道为主的可能为女性）。例如网页申请QQ帐号和注册网易通行证等

网页申请QQ （qq.com）帐号

注册网易（163.com）通行证

雅虎（yahoo.com）的设计比较特立独行，使用选择框（select），并默认不选中任何一个。

而雅虎中国（yahoo.cn）的设计也是使用单选框（radio），但是不选中任何一个。

按常理来说，注册系统并不知道用户的性别是什么，默认选中任何一个都不合理。yummy有一篇文章《中文按1，For English, press 2》提到“如果用户必须做出选择，那就先给他做好一个选择。”，这个道理在某些情况很不错，但是用在这里不合适。

如果不足够了解用户，就不要替用户做选择。

标签模式

目前的标签有以下几种模式(形式)：

1. 手动外联标签模式。
这种模式将标签和内容分离，用户需要为指定文档/内容贴上不同的标签。例如Gmail和新版Wordpress的标签。

优点：简单易用，可控性强。
缺点：需要为每个内容设置标签。


2. 手动内联标签模式。
这种模式将标签和内容融合，用户同样需要为文档/内容贴上不同的标签，并且这种模式因为没有明确的标签输入区（标签输入区和内容输入区在一起），容易导致忘记贴标签，对于及时性和不可修改性的应用不太理想。如Twitter就有这方面的第三方应用，参考hashtags。

优点：内容被语义化；标签本身简单易用，可控性也很强。
缺点：需要辅助标记，内容被干扰；容易忘记使用标签。

3. 自动内联标签模式。
这种模式需要用户手动设置标签集合，系统根据内容自动匹配标签。目前还没有发现这种模式的实际应用，比较接近的有关键字替换和对局部文本进行评论（忘记怎么称呼了，也没找到相关网址，请大家给提个醒）。关键字替换只是展示层的，用户可以根据内容发现（暂且称之为）标签，但无法通过标签找到匹配的内容（由此想到了搜索引擎）。

优点：标签自动化，用户无需操心内容和标签之间的关系。
缺点：要匹配到正确的标签并不容易，大概到真正的语义时代可以解决。

由此扩展另一种：

4. 内联标签兼容模式。
系统根据用户设置的标签集合管理标签与内容之间的关系，另外用户也可以手动管理标签。
优点：标签自动化；可控性强。
缺点：简单问题变复杂，包括系统实现复杂度和用户使用复杂度。

不过回头想想，标签本身很简单，有必要把它变复杂吗？自动化就是不想手动控制，如果需要手动控制还要自动化干嘛？

关于面包屑导航

一直都很喜欢千鸟志的标题面包屑导航方式，我准备在自己的博客主题中使用这种导航。

不过，千鸟志的导航部分和标题有重复（另外我比较倾向于使用标签而不是分类）。下面将导航和标题融合，去除标题部分。

这里使用了语义化的标签，并且在字体和颜色上突出当前的状态，与标题融合的也算恰当。不过当标签较多时会将标题挤到很靠后。
另外想到有一些Unix论坛使用的树形导航也不错，稍加改进如下：

标签应用比上面稍合理，而且css裸奔情况下表现也略如人意（话说“差强人意”这个词的“差”是“甚，殊”的意思）。对于导航层级不太深的应用，还是不错的。

改进的菜单按钮

一直想写关于菜单按钮的设计，但是太懒惰的原因，老是拖着不做。
当然今天也没勤快到哪里去，下面第二个改进图是用Pencil画的，并没有用脚本实现，哎，懒啊。
先看QQ/TM的设计，无论选项是什么，按钮上都没有体现出来。

我觉得其实不论是文本，还是图标，都可以把当前选中状态体现在按钮上的，便于用户确认按钮当前的状态。下面是改进后的菜单按钮（以QQ/TM为例）。

一般来说，菜单按钮都应该做用户“最后一次”使用选择的动作。
例如早期QQ的视频、语音菜单按钮，MSN的菜单按钮，还有旺旺的菜单按钮，都应该如此。

电梯按钮设计

1. 外面选择“上”或“下”的按钮换成“开门”，这样外面也可以中断自动关闭的电梯门，并增加选择楼层按钮。这样电梯系统可以预知各个起始楼层和目标情况，可以结合历史数据合理调整运转过程，对用户来说，也不必都挤在电梯里忙着（或忘记）选择目标层；
2. 选择“上”、“下”以及楼层的按钮可以取消选中。建议如下：当前被选中，则按一下取消选中，否则选中。目前有一些稍人性化的电梯可以取消操作，但是要按N下，而一般用户又不知道N等于几？其实按一下就够了，不过避免误操作，连续按两、三下取消也可以，并在旁边给出提示；
3. 里面保留选择上、下和楼层按钮（用户可以中途改变目标），但是选择楼层的按钮应该放到开、关门按钮的下面，方便儿童和残障人士使用（开、关门是自动的，影响不大）。

这个改造成本不知道算不算大，每一层都需要增加选择楼层的按钮，不过这对用户和系统都是有利的，为电梯系统设计的合理也做了准备。我觉得这是未来电梯的最低配置。

由邮件排序想到的

目前的电子邮件系统，均是使用倒序列出邮件列表，最新的邮件总是在第一封。这样做也并没有什么不好，不过这是最好的排列方式吗？

新邮件很容易将较早的邮件挤到下面甚至是后面的页面中，导致最先收到的邮件反而最后被看到，这就出现了公平性问题，当然并不是先到的邮件就一定要先看，甚至邮件被直接无视也有可能。而另一个问题是，同一个人连续发了多封相关邮件，这就出现了错误阅读顺序的问题，如果是最后一封修正前面错误的，而最后一封又有全文引用的话，看这最后一封就可以了，但如果没有引用呢，不看前面的邮件确实会摸不着头脑（Gmail的会话功能对这一问题处理较好）。

一般来说，有效率的人不会在收件箱保留过多未读邮件，所以收件箱邮件被分页的情况会比较少见（受欢迎的收件人例外），所以按顺序排序是个不错的选择。

另外如果收件箱或者存档箱中确实需要分页该如何排序？我的想法是“总倒序，分顺序”，即总体数据是按倒序排列的，而被分页的页面则使用顺序排列显示。效果：第一页就是最后一页，而显示页每一封邮件则按顺序排列。

后来在VeryCD看到一个更好的方案：所有数据按顺序排列，但是默认（首次）显示的是最后一页。细节上可以有一个更好的改进：默认页将尽可能多的显示内容。例如默认每页显示50条评论，当总共有60条评论时，默认显示第2页，而第2页按顺序排列显示50条，第一页显示10条。

当然最好的情况是综合类似Gmail会话功能的方式，将相同主题归为同一个会话中，这类似于Wordpress的一个评论插件（效果参看aw's blog，新版Wordpress好像已经内置该功能了）。

个人意见综述：

• 收件箱邮件列表完全使用顺序排列。先到先被看，这样我就不会因为希望得到重视，在周日写好的邮件，却等到周一才发出去了；处理较早有邮件也合乎常理。
• 评论、留言、邮件存档箱使用顺序排序，默认显示最后一页。这样的话，像Wordpress这样使用英文语言，放在底部左侧的Older Posts也不会觉得别扭了。
  

p.s. 另外发现draft.blogger.com的自动保存还是很人性化的，不是使用定时自动保存，在用户输入过程中不会瞎保存影响用户，而是在输入停顿时才自动保存。这有点类似我的节奏感知器上运用的思想。

文本宽度 及 文本框滚动偏移量(scrollLeft)

背景：
最近将多标签输入框进行修改，把原来随光标(caret)移动的自动建议浮动条改为根据当前标签相对左对齐。

解决方法很简单，计算当前标签前的文本宽度(将需要计算的文本转义后放入一个各字体样式与目标输入框相同的容器，如span中，span.offsetWidth即是文本的宽度。注意：文本框中，中文半角空格的宽度和英文半角空格的宽度显示为不同，虽然这两个空格本质上相同)，浮动条根据该值定位即可。

问题：
当标签文本过长，超出文本框宽度时，标签文本会向左滚动，但是此时当前标签前面的文本宽度不变，定位浮动条时需要减去文本向左滚动的尺寸。

网页文档对象中，元素都有一个可读写的scrollLeft属性，表示元素内容相当元素容器向左移动的偏移量。

但是Firefox和Opera有一些例外，如文本框的scrollLeft始终为0，Mozilla的描述是：

If the element can't be scrolled (e.g. it has no overflow), scrollLeft is set to 0.

对于一些不可滚动(scroll，即没有溢出)的元素，scrollLeft始终为0。而单行文本框（在Gecko引擎看来）是不可滚动的，即使将样式指定为overflow:scroll（IE会出现水平和垂直滚动条这样的怪胎）。

虽说单行文本框是不应该出现滚动条这样怪异的形态，但是这不表示它是不可滚动的，当文本宽度大于文本框宽度时，（为了将光标caret显示在文本框可见区域）文本势必向左滚动，如图：

解决办法：
对于文本框不支持scrollLeft的浏览器，一个临时的解决办法是，在文本宽度大于文本框宽度时，浮动条定位在相对文本框后端若干像素（便于输入）的位置，在增量输入时，体验不是太差，但是在光标向前移动使文本向右滚动时，就会出现偏差。

最终解决办法是期待浏览器能够得到正确的scrollLeft值，或者其他巧妙的计算方法。